►
From YouTube: Discovery conclusion and UX review: auto-remediation MVC
Description
0:00 - 1:26 • context and current UX
1:26 - 12:12 • MVC review
12:12 - end • resulting issues and next steps
Issue update: https://gitlab.com/gitlab-org/gitlab/issues/14059#note_245374632
Walking through a design iteration of auto-remediation MVC. This focuses on step 1. which is to auto-create merge requests that includes fixes to vulnerabilities. Our next step 2. will focus on auto-merging MRs with fixes to further automate the workflow.
A
So
in
this
discovery,
we've
been
focused
on
producing
an
MVC
for
the
auto
creation
of
merge
requests
very
quickly,
walk
through
what
our
current
baseline
is
just
to
understand
where
we're
currently
at
with
our
capability.
So
if
you
use
dependency
scanning
and
yarn
with
dependency
scanning
you,
you
may
see
some
vulnerabilities
in
the
security
dashboard
here.
As
we
see
here,
you
may
click
on
one
of
these
vulnerabilities,
and
here
you
would
see
that
a
solution
is
available
again.
This
is
just
for
dependency
scanning
with
projects
using
yarn.
A
The
UX
problem
here
is
that
the
user
wouldn't
have
even
known
that
a
solution
is
available
on
the
security
dashboard
here
anyway,
moving
on
the
options
at
this
point
for
the
user,
when
they
open
the
modal
would
be
to
resolve
it
with
a
merge
request,
download
the
patch
locally
or
create
an
issue,
let's
say
that
they
resolved
it
with
a
merge
request.
It
would
then
take
them
to
a
merge
request
with
the
solution
available
from
there.
A
This
is
a
follow
up
on
a
second
iteration
that
we
walked
through
and
since
then,
we've
talked
with
front
end
and
back
end
again
to
get
further
feedback
and
to
identify
our
next
steps
for
an
MVC
and
a
path
forward.
So
where
we've
landed
is
similar
to
the
second
iteration.
Although
there
was
some
trade-offs
that
we'll
have
to
make
one
of
the
main
trade-offs
is,
is
we
really
wanted
this
to
work
out
of
the
box?
A
And
that
means
if
the
user
configured
dependency
scanning,
that
auto
room,
auto
creation
of
these
merger
quests
when
available,
would
automatically
happen,
so
they
never
had
to
go
hit
on
button
or
anything.
It
just
worked.
The
only
thing
if
they
wanted
to
turn
it
off
is
that
option
to
opt
out
would
be
available.
A
However,
we
ran
into
a
roadblock
there,
and
that
is
the
following:
is
that
we
don't
currently
have
a
bot
or
get
or
or
a
ghost
user
that
we
can
use
for
the
auto
created,
merge
request.
So
in
a
previous
video,
this
was
one
of
the
outstanding
questions
that
we
talked
about,
and
it
will
be
a
more
involved
issue
that
we
will
take
a
look
at
separately,
so
we'll
open
up
a
separate
issue
to
that
or
put
that
in
our
next
discovery
to
address
in
the
interim
for
the
MVC.
A
What
we're
proposing
is
on
the
configuration
screen
after
the
user
has
successfully
had
it
configured
dependency
scanning
they'd
be
able
to
check
this
box
to
default,
to
auto
fix
when
solutions
are
available.
The
UI
is
mirroring
and
very
similar
to
the
pattern
seen
with
defaulting
to
auto
DevOps.
So
when
the
user
selects
default
to
auto
fix
when
solutions
are
available,
a
message
would
appear
again.
This
is
very
similar
to
Auto
DevOps
interaction,
because
a
message
sometimes
appears
there
as
well
for
more
information,
but
this
is
just
letting
them
know.
A
The
user
who
enables
this
auto
fix,
will
be
the
author
of
the
auto,
created,
merge
request
and
it
links
to
more
information
in
our
documentation.
So
that
means
that
if
I
was
the
user
here
and
I
click
that
that
I
would
be
the
author
of
that
in
the
previous
a
previous
way
to
handle.
This
would
be
that
the
user
would
have
to
designate
an
author.
But
there's
two
challenges
here:
that
I
just
want
to
highlight,
and
that
is
again
that's
additional
required
configuration.
A
We
want
to
get
away
from
any
additional
configuration
needed
and
then
the
other
thing
is:
is
there's
audit
log
implications,
so
that
is,
let's
say
that
I'm,
enabling
this
feature,
but
I
select,
tally
to
be
the
author.
Tally
doesn't
really
have
awareness
of
that,
and
then
she
may
find
that
she
has
these
Mert
request
that
she
authored-
and
she
wouldn't
really
know
why.
A
So
the
discovery,
the
discoverability
of
these
solutions
would
be
the
following.
So
since
this
MVC
there's
an
opt-in
or
opt-out,
there
could
be
two
cases
that
we
need
to
cover
for,
and
one
kind
of
is
for
our
existing
UX,
which
needs
to
be
enhance,
which
is
not
giving
the
user
any
insight
when
solutions
are
available.
So
this
is
a
very
worthwhile
fix
anyway,
for
that
case,
and
the
second
case
would
be
when
the
opt-in
is
active.
A
This
UI
is
based
on
their
most
up-to-date
upcoming
dashboard
UI
/
first-class
objects.
So
that's
just
a
side
note,
but
in
that
will
will
have
messages,
user
left,
met
user
generated
messages
or
notes.
That
would
be
there.
We
will
also
add
this
little
light
bulb
icon
to
surface
it
from
right
from
the
dash
indicating
that
a
solution
is
available.
Now,
let's
say
that
the
the
feature
is
oft
in
and
it's
configured.
What
we'll
do
is
well
will
have
the
merge
request
linked
directly
from
here.
So
that's
the
auto
created
merge
request.
A
This
is
following
a
similar
pattern
that
we
already
see
is
when
a
vulnerability
has
a
related
issue
to
it.
It's
seen
in
the
same
way,
so
we're
adopting
that
same
pattern
and
using
it
here
and
when
we
walk
through
the
flows.
That'll
that'll
help
out
that
user
flow
from
that
and
we'll
take
a
look
at
that
in
just
a
minute.
A
Otherwise,
since
this
is
related
to
dependency
scanning,
we
will
also
see
this
merge
request
link
on
the
dependency
scanning
page.
At
the
moment,
the
dependency
scan
vulnerabilities
are
not
clickable,
there's
a
separate
issue
for
that
to
fix
that,
but
the
current
UX
is
that
we
do
show
when
vulnerabilities
exist
for
dependencies
and
there's
a
drop
down
here.
That
shows
what
they
are
and,
in
this
case,
we'll
be
able
to
put
the
merge
request
there.
So
those
are
all
the
places
that
this
would
appear
in
terms
of
discoverability.
A
A
We
looked
at
of
a
dedicated
filter
here
for
those
auto
fixed,
auto
generated,
merge
requests,
however,
that
would
be
a
significant
amount
of
work,
and
this
is
per
back
and
feedback
and
kind
of
out
of
the
scope
of
an
MVC
something
we
definitely
want
to
look
at
later,
but
this
is
a
fair
trade-off.
Given
how
limited
our
current
capability
set
is,
but
but
definitely
in
the
in
the
former,
a
direction
we
want
to
do
so.
A
The
alternative
that
we're
taking
look
at
here
would
be
an
auto-generated
label
for
these
Auto
created,
merge
requests
and
that
could
then
be
discovered
in
this
way
in
the
same
pattern
that
you'd
go
and
select
the
label,
they
would
chop
this
down
and
then
select.
Let's
say
that
the
name
of
it
was
vulnerability,
auto
fix,
so
that
would
then
show
these
and
again
that
label
would
be
system
generated
when
when
the
merge
requests
are
auto
created
now.
A
The
downside
of
this,
of
course,
is
that
maybe
the
customer
has
already
created
a
label
with
the
same
name.
There
is
an
edge
case
there,
but
I
think
that
this
is
something
we
want
to
keep
our
eye
on
and
come
up
with
a
solution
for
our
next
discovery
to
solve
for
again
going
back
to
something
more
similar
of
that
direct
filtering
capability.
A
A
Excuse
me,
the
user
could
see
the
light
bulb
and
they
click
on
the
table
room,
and
this
is
per
upcoming
changes
to
the
security
dashboard
anyway,
and
then
they
would
land
on
the
objects
page
and
from
here
you
see
the
ability
to
resolve
with
merge
request
or
that
drop-down
could
also
create
a
new
issue
or
download
the
patch
locally
and
let's
say
they
resolved
with
merge
request.
It
would
then
open
up
a
merge
request
if
they
have
it
enabled
that
the
merge
request
link
would
be
visible
right
there
on
the
screen,
as
we
saw
earlier.
A
The
big
benefit
of
this
is
that
they
could
just
click
that
directly
and
go
right
to
the
merge
request.
Of
course,
they
could
still
do
the
other
route
where
they
click
the
table
row
to
go
to
the
objects
page,
but
with
this
visibility
of
a
merge
request
right
here
on
this
page,
that
saves
that
extra
click
and
gets
them
right
to
the
merge
request.
A
Ok,
so
that
pretty
wraps
up
the
overview
of
the
NBC-
oh
I'll,
actually
just
add
in
one
other
thing,
we
do
want
to
bring
more
awareness
to
this
feature
and
one
way
that
we
can
do
this
without
creating
noise
or
or
assigning
Auto
signing
people
is
to
put
a
banner
perhaps
on
the
security
dashboard.
That's
stating
when
these
vulnerabilities
have
been
or
excuse
me
when
these
solutions
and
these
auto
created
merch
requests
have
been
created.
A
So
in
this
case,
this
state
sadness
in
this
messaging
banner
and
the
user
could
view
security
fixes
which
would
take
them
to
the
auto
filtered
merge
request
page
with
the
label
that
we
discussed
from
here.
They
could
go
ahead
and
merge
these
merge
requests
or
at
least
take
a
look
at
them.
So
that's
kind
of
a
proactive
effort
to
bring
awareness
to
the
user.
A
Further
awareness
to
the
user
about
this
okay,
some
of
the
next
steps
that
we're
going
to
take
a
look
at
that
we're
recommending
from
this
discovery
is
the
implementation
of
the
above
MVC.
That
we
saw
above
there's
certainly
some
trade-offs
that
we
made.
However,
it's
it's
something
that
UX
and
front-end
and
and
back
in
felt
we
could
get
in
a
milestone
or
two,
and
it
really
does
lay
the
foundation
for
us
to
start
building
and
improving
on
the
next
recommendation
here
or
the
next
issue
that
we'll
be
creating
next
step.
A
That
we'll
be
doing
is
a
UX
research
issue
and
we
really
want
to
take
a
look.
We
really
want
to
test
what
we
just
looked
at
some
of
the
designs
and
get
some
insights
from
users
about
usability
and
usefulness
and
some
feedback
on
how
we
can
better
iterate
on
on
the
next
step,
and
that
next
step
is
a
discovery
focused
on
Auto
merging
the
auto
created,
merge
request.
A
So
that's
the
main
focus
of
that
discovery,
the
other
things
that
we
want
to
reevaluate
and
that
discovery
is
looking
at
filtering
by
auto
fix
sections
and
not
relying
on
the
auto
created
label.
So
having
a
dedicated
filtering
section,
this
will
become
important
as
we
expand
our
capabilities,
for
example,
where
we're
gonna
be
adding
or
we're
currently
looking
at
container
scanning,
auto
fixes.
So
once
we
have
multiple
fixes
available
and
once
this
starts
growing,
this
is
going
to
be
pretty
important.
A
So
we
want
to
reevaluate
that,
and
we
also
want
to
reevaluate
the
author
of
these
auto
created,
merge
request
once
these
odd
once
these
merge
requests
are
Auto
merging.
This
will
help
this
situation
of
the
author,
but
still
I
think
we
want
to
at
least
take
a
look
at
if
there's
a
ghost
user
or
a
bot
or
designated
user
out
there,
we
did
find
that
in
the
past
there
was
a
sort
of
ghost
user
triggering
pipelines,
although
this
was
actually
deprecated
some
quite
quite
a
while
ago.
A
Actually,
but
but
anyway,
we
want
to
take
a
look
at
that
and
see
if
there's
other
use
cases
for
this
I
know
there
was
some
discussion
with
first-class
objects
when,
when
creating
some
of
the
objects,
there's
a
git
lab
pod
or
some
challenges
there
as
well,
so
maybe
there's
other
areas
where
this
could
help.
So
we
want
to
take
a
look
at
that
and
then
a
follow-up
issue
evaluating
some
of
the
solutions
that
we
find
from
this
discovery
of
auto
merging
and
Auto
creating.
A
So
that
gets
us
in
the
cycle
of
NBC
research,
validation,
gain
insights
to
our
next
discovery
and-
and
then
repeat
repeat
so,
we're
constantly
informing
our
discoveries
and
our
implementation
issues.
So
anyway,
that
wraps
up
the
the
conclusion
for
this
Auto
remediation
issue
and
yeah.
If
you
have
any
thoughts
per
usual,
please
drop
us
a
note
in
the
to
itself
or
send
us
an
email
directly
at
came
in
at
gitlab
dot-com.