►
From YouTube: UX iteration review: auto-remediation MVC
Description
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.
Issues update: https://gitlab.com/gitlab-org/gitlab/issues/14059#note_240956001
A
But
at
the
moment
the
scope
is
limited
to
projects
using
yarn
with
dependency
scanning,
but
overall
we're
aiming
for
a
generic
UX
approach
to
accommodate
multiple,
auto
remediation
capabilities.
So,
for
example,
another
one
that
we're
working
on
is
Auto
emission
over
mediation
for
container
scanning.
A
A
So
from
the
security
dashboard
we
show.
Different
vulnerabilities
in
this
screen
were
filtered
down
the
dependency
scanning
again.
Our
current
capability
set
is
limited
to
dependency
scanning
with
projects
using
yarn.
So
let's
say
that
I
hovered
over
one
of
these
table
rows,
which
is
at
vulnerability
and
I,
took
a
look
at
more
info.
A
The
information
here
is
blocked
out
for
sensitive
information
since
its
vulnerability,
but
the
focus
is
on
what
we're
taking
a
look
at
at
this
point:
I
notice
that
there
is
a
solution
available,
so
one
UX
problem
that
I'll
call
were
out
right
now
is
going
back
to
this
screen
as
a
user.
I
wouldn't
have
had
any
insight
that
one
of
these
vulnerabilities
has
an
own
patch
that
a
system
actually
has
a
patch
and
a
fix
available,
not
until
I
open
up
the
details
screen.
So
that's
not
so
good,
but
either
way.
A
My
options
from
here
would
be
to
resolve
with
a
merge
request,
so
that
would
create
a
merge
request,
download
the
patch
locally
or
create
an
issue
around
it
to
follow
through
with
this
flow,
we'll
take
a
look.
It
would
just
open
up
the
merge
request
and
some
of
the
details
provided
would
be
added
to
the
description.
A
So
that's
currently
we're
at
again.
What
we'd
like
to
do
now
is
look
at
how
we
can
have
merge
requests
with
fixes
automatically
created,
so
we're
gonna
walk
through
what
that
might
look
like
and
in
the
different
areas
from
settings
where
the
user
would
see
the
fixes
that
are
available
and
future
considerations
for
this
okay.
So
the
current
recommendation
is
that
we
have
this
on
by
default.
A
In
this
case,
if
dependency
scan
is
configured
correctly,
it
would
be
activated
and
of
course,
if
they're
using
yarn,
if
they
wanted
to
turn
it
off,
they
would
come
here
to
leftnav
to
the
security
and
compliance
section
and
go
to
configuration,
and
we
have
this
upcoming
configuration
screen
that
gives
the
status
of
whether
or
not
a
certain
skin
is
configured
or
not
yet
configured,
but
we
could
also
add
the
auto
fix
vulnerabilities
to
this
section.
As
you
see,
dependency
scanning
is
configured
therefore,
and
this
auto
fix
is
automatically
on.
A
If
the
user
wanted
to
turn
it
off,
they
would
have
to
just
uncheck
the
box.
There's
an
ongoing
discussion
about
where
to
put
certain
settings
right
now,
since
the
configuration
screen
for
secure
exists.
We
went
in
this
direction,
but
this
is
something
we'd
like
to
take
a
closer
look
at
in
some
upcoming
research
to
make
sure
that
the
information
architecture
is
a
line
with
where
users
would
naturally
navigate
to
to
change
settings
like
this
one
okay.
A
So
we
have
solutions
available
for
vulnerabilities.
Where
would
the
user
see
this
and
how
would
they
know
that
these
merge
requests
were
created?
Okay,
so
this
would
be
based
on
our
current
capabilities.
This
would
be
based
located
in
two
areas.
One
again
would
be
where
it
is
now
on
the
security
dashboard.
A
These
designs
are
based
on
our
current
and
upcoming
work
with
first-class
objects,
which
changes
the
table
and
the
workflow
a
little
bit
which
we'll
get
to
in
a
moment,
but
just
want
to
show
in
terms
of
awareness
where
this
would
appear,
and
so
in
this
case
next
to
the
messaging
icon.
It
takes
priority
that
there's
a
solution
available
also
since
it
pertains
to
dependency
list
now.
A
We're
looking
at
the
dependency
list
and
vulnerabilities
are
now
shown
on
the
dependency
list,
and
if
a
fix
is
available,
we
can
display
the
same
icon
for
consistency,
I
think
in
the
future.
We
definitely
want
to
improve
this
visibility,
but
as
an
MVC
and
working
into
what
some
of
our
other
work
is
like
I
said
with
first-class
objects,
we
want
to
keep
it
as
minimal
as
possible
right
now
to
make
sure
that
our
efforts
are
aligning
as
as
we're,
shipping
different
features
on
to
security
dashboard,
and
so
we're
not
adding
too
much
at
one
time.
A
Okay,
so
let's
take
a
look
at
the
workflows
of
the
user,
identifying
a
auto
created,
merge
request
and
the
workflow
going
to
that
merge
request
to
merge
it.
Something
we
haven't
chatted
about
yet
is,
since
merge
request
would
be
auto
created,
they
would
also
appear
in
the
merge
request
list.
This
shows
the
this
flow
shows.
These
are
actually
filtering
down
to
show.
Only
the
auto,
created
or
auto
fix,
merge
request,
and
that
would
just
be
using
the
same,
familiar
pattern
that
we
have
now
and
that
would
be
the
user
clicking
into
this
filter
input.
A
A
Let's
take
a
look
at
the
flow
when
the
user
navigates
from
the
security
dashboard,
as
we
saw
earlier,
and
this
is
based
on
some
upcoming
work-
that
has
four
first
class
objects
where
the
security
dashboard
is
a
little
bit
different
than
we
saw
in
our
baseline
experience
that
we
walk
through.
So
in
this
case,
we
see
that
the
there
is
a
solution
available.
The
user
could
click
the
table
row
in
in
the
upcoming
work
for
the
dashboard.
The
different
icon
options
for
more
info
are
not
there.
That's
there
to
simplify
the
experience.
A
So
in
this
case
the
whole
table
row
is
clickable
and
then
there
will
land
on
the
vulnerability
information
page.
This
just
gives
some
data
about
what
the
vulnerability
is
and
so
on
from
here
they
will
see
that
the
solution
is
available.
Let's
view,
all
the
call
to
action
is
to
view
the
auto
fix,
merge
request
and
they
click
that,
and
then
they
land
on
the
merge
request.
A
Some
of
the
notes
here
are
that
right
here
with
annotation
one,
this
would
be
the
system
author
so
could
be
administrator
could
be
the
get
lab
bot
something
of
that
nature.
Human,
don't
create
this
merge
request.
So
whatever
the
author
may
be
this,
however,
we
want
to
title
that
it's
still
something
where
we're
discussing,
but
it
seems
like
the
get
lab
bot
or
administrator.
Some
sort
would
want
to
do
that
number
annotation.
A
It
shows
the
title
we
want
to
put
in
a
sort
of
template
here
which
would
be
auto
fix
and
then
CV
in
this
case.
That
was
taken
from
a
description
of
the
available
patch
and
we
can
give
them
a
link
in
the
description
to
how
autumn
remediation
work.
So
they
can
have
a
little
bit
more
information
about
that.
We
can
link
the
code,
change,
that's
actually
being
made
and
then
description
and
someone
would
be
extracted
from
the
data
that
we
have
about
the
patch.
A
In
example,
what
I
mean
by
that
is
Adam
Cohen
is
actually
currently
working
on
auto
remediation
for
container
scanning
I
believe
this
will
be
a
follow
up
to
what
we're
working
on
now,
but
for
the
fixes
that
they
have
here
are
some
of
the
information
that
we
have.
So
we
could
use
the
fix
by
as
the
title
we
could
use
the
vulnerability
as
a
title.
This
is
one
of
the
decisions
we
would
want
to
make,
but
either
way
this
is
just
a
show.
A
A
They
would
be
seen
here
we,
you
could
filter
down
by
auto
fix
in
the
merge
request
area,
and
then
you
could
further
filter
by
the
precise
type
of
scan.
That
is
so
perhaps
dependency
scan
containers
game,
whatever
the
names
are
of
the
future
capabilities
and-
and
in
this
case,
we're
showing
just
all
fixes,
but
all
this
to
say
that
this
direction
has
a
consistent
UX
for
these
feature
capabilities.
A
Another
idea
that
we
want
to
explore
is
we
want
to
continue
to
bring
more
visibility
and
awareness
to
these
auto
created
in
Mars,
one
and
and
just
general
visibility
to
the
future.
This
is
showing
a
messaging.
That's
in
the
security
dashboard.
That's
bringing
attention
to
security.
Vulnerabilities
have
been
found
that
have
fixes
merge,
requests.
A
It's
bringing
awareness
to
the
user
that
these
auto
created,
merge
requests
have
been
created,
and
this
is
giving
them
a
direct
path
to
that
and
when
they
land
here
in
the
merge
request
page,
there
is
a
certain
aspect
of
learnability
here
that
the
auto
fix
exists
they're
in
their
normal
workflow,
so
that
may
help
them
understand
the
feature
as
well.
Another
thing
is:
is
this
may
be
useful
in
our
second
step,
which
I
said
earlier,
which
is
Auto
merging
of
Auto
created,
merge
requests.
In
that
case,
you
would
have.
A
You
could
have
a
potential
issue
with
auto-created
merchant
requests
that
are
getting
Auto
merge
that
faith
for
whatever
reason,
and
we
want
to
bring
that
to
their
attention.
A
similar
type
of
messaging
could
be
brought
to
them
in
those
outlier
cases
when
we
want
to.
Let
them
know
that
you
know
1
out
of
10
or
something
or
a
small
handful
of
Auto
merge
did
not
pass
or
the
pipeline
failed,
so
this
can
be
used
in
in
some
different
ways.