►
From YouTube: Baseline Experience: Security Dashboard
Description
Walking through "job to be done" baseline experience: When reviewing vulnerabilities for multiple projects, I want to see them all in one location, so that I can prioritize my efforts to resolve or triage them while seeing the larger picture.
Overview: dashboard feature is at an early product stage and considered an MVP. The user we are designing for works in an organization's web security department. Roles such as: security analysts, security engineers, or head of security. Although, some mid-to-smaller organizations may not have a dedicated security department, in this case the users would likely be: developers, tech leads, and devops engineers.
Links:
Security Dashboard Documentation: https://docs.gitlab.com/ee/user/application_security/security_dashboard/
Baseline Initiative: https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations/#grading-rubric
Issue: https://gitlab.com/gitlab-org/gitlab-design/issues/401
A
Hi
I'm
Kyle
the
product
designer
at
gate,
lab
on
the
secure
team
today,
we'll
be
looking
at
one
of
our
secure
features:
the
security
dashboard.
This
is
a
feature,
that's
included
in
our
ultimate
tier.
It's
important
to
note
that
it's
at
an
early
product
development
stage
and
is
currently
considered
an
MVP,
the
user.
We're
designing
this
for
would
likely
work
at
an
organization's
web
security
department.
A
The
dashboard
is
intended
to
provide
the
user
with
an
overview
and
awareness
of
vulnerabilities
spread
over
multiple
projects,
while
providing
the
ability
to
resolve
vulnerabilities
and
be
proactive
about
addressing
a
number
of
projects.
Security
concerns
a
bit
more
background
about
this
video.
The
gait
lab
design
team
is
currently
doing
an
audit
of
all
of
our
product
stages
documenting
our
key
user
tasks
baselines.
This
is
also
known
as
jobs
to
be
done,
which
are
tasks
through
the
users
eyes.
A
The
taffer
reviewing
today
is
the
following:
when
reviewing
vulnerabilities
for
multiple
projects,
I
want
to
see
them
all
in
one
location,
so
that
I
can
prioritize
my
efforts
to
resolve
or
triage
them
while
seeing
the
larger
picture.
Okay,
let's
dive
into
it,
the
user
would
first
come
here.
This
is
the
groups
page
there's
two
things
that
could
happen
here.
If
the
user
hasn't
already
set
up
the
group
of
projects
they
one
user
would
set
this
up
by
clicking
new
group
here
and
then
selecting
the
projects
they
want
to
be
part
of
that
group.
A
Okay,
we're
on
the
group
landing
page
from
here.
The
user
would
go
to
the
security
dashboard
now
we're
at
the
security
dashboard
and
just
scroll
up
and
down
to
take
a
look
at
what
we
got
here.
Okay,
so
we
see
some
filters
at
the
top.
We
see
a
high-level
overview
of
the
vulnerabilities
that
are
in
this
group
there's
a
chart
here
that
shows
vulnerabilities
detected
over
time
and
then
there's
a
list
of
different
vulnerabilities
in
this
group.
A
Let's
start
with
the
filters,
this
is
intended
to
help
users
prioritize
the
vulnerabilities
that
they
want
to
take
a
look
at,
for
example,
with
severity.
They
could
prioritize
to
critical.
Only
next
is
report
type.
This
is
important
because
these
are
the
actual
reports
from
the
scanned
fault
from
the
secure
features
that
we
have
here.
It's
important
to
understand
what
these
different
scans
do.
Let's
start
with
container
scanning
this
checks,
docker
images
for
known
vulnerabilities
in
the
application
environment.
A
A
This
is
dynamic,
application
security
testing,
it
analyzes
deployed
running
web
applications
for
known
runtime
vulnerabilities,
and
we
have
dependency
scanning.
This
analyzes
external
dependencies
for
vulnerabilities
on
each
code
commit
with
gitlab
CI
CD.
An
example
of
this
could
be
libraries
like
ruby,
gems
and
then
the
last
one.
This
gives
the
user
the
ability
to
drill
down
on
certain
projects.
A
Let's
scroll
down
a
bit
the
chart
should
help
the
user
see
vulnerabilities
over
time.
Perhaps
so
let
them
identify
themes
and
certain
times
that
they
should
be
aware
of.
Just
in
the
ability
to
look
at
30
60
90
days,
the
idea
here
is
that
they
have
a
broader
picture
of
how
these
are
built.
These
vulnerabilities
are
affecting
their
application
and
when
now
we
have
the
list
of
the
vulnerabilities
themselves
from
here,
the
user
can
hover
over
and
there's
some
quick
actions
for
them.
Let's
review
those
really
quickly.
A
A
This
helps
prioritize
in
terms
of
these
that
they
may
be
aware
of,
but
they're
not
interested
in.
They
can
go
ahead
and
just
dismiss
it
right
here
for
once
that
they
know
immediately
need
to
be
dealt
with.
They
can
hit
create
issue.
The
great
thing
about
this
is:
it
takes
all
the
details
that
was
identified
from
the
scans
and
adds
that
to
an
issue,
description
right
here
and
it's
open
now,
what
they
can
do
is
immediately
start
a
conversation
around
this
issue.
A
Let's
go
back,
let's
say
that
we
wanted
to
find
out
a
little
bit
more
user.
Could
either
click
here
on
the
title,
or
they
could
click
more
info
from
here?
This
gives
some
more
information
that's
relevant,
such
as
where
the
actual
file
vulnerability
is
what
file
that's
in
unique
identifiers,
the
class
and
some
links
to
help
them
understand
what
the
vulnerability
is
and
potentially
resulted.