►
Description
0:00-4:23 Context and flow configuring SAST, License Compliance, Dependency Scanning
4:23-9:47 Proposal when the user selects to configure DAST and/or Container Scanning UX
9:47-12:27 Related flow: untested projects on group dashboard anchors to the project configuration screen
Related issue: https://gitlab.com/gitlab-org/gitlab/issues/34771
Related video: https://www.youtube.com/watch?v=gKtVOMt5WO0
A
Hi
I'm
kyle
from
the
secure
UX
team,
and
today
I
want
to
walk
through
the
latest
iteration
on
our
MVC
proposal
for
enabling
users
to
configure
security
analyzers
directly
from
the
UI.
With
a
merge
request.
The
MVC
is
intended
to
facilitate
the
existing
workflow
of
configuration,
while
really
trying
to
improve
the
learn
ability
for
the
user
on
how
these
analyzers
are
set
up
or
project.
A
The
focus
today
is
improving
on
a
loose
end
for
gas
and
container
scanning
and
making
sure
that
were
not
walk-in
users
into
a
failed
pipeline
and
take
a
closer
look
at
why
that
would
be
a
case
in
just
a
minute.
I
did
link
a
longer
video
that
kind
of
walks
through
this
flow
more
extensively
and
the
discovery.
A
Just
walking
through
this
flow,
though,
rather
quickly,
so
if
we're
on
a
project
right
now
and
if
the
user
came
to
this
security
and
compliance
section
here
in
the
left,
navigation
and
selected
configuration,
they
would
land
on
this
configuration
page.
There's
the
ability
with
these
radio
boxes
then
to
select
them.
So
let's
say
that
we
select
SAS
and
dependency
scanning
and
licence
complaints.
A
We
then
have
an
active,
create,
merge
request,
but
when
the
user
initiates
that
there
are
some
system
actions
that
would
take
place,
which
is
identifying
if
a
animal
exists-
let's
say
it
does
well
Malik,
reiated
or
added
this
respective
template
will
be
added
to
that
file
to
the
default
branch.
The
changes
will
be
committed,
it'll
trigger
a
pipeline
and
merge
requests
created
will
be
created
with
the
changes.
A
That
can
be
seen
in
the
changes
and,
of
course,
the
commits
that's
made,
but
those
are
the
core
requirements
and
of
course,
there
are
other
variables
to
each
of
those
that
could
be
added
and
that's
why
we're
surfacing
the
documentation
here
that
they
can
take
a
closer
look
at
them
individually,
but
they
have
a
unified,
merge
request
right
now,
with
the
templates
ready
to
go
so
they
could
merge
it
from
here
or
they
could,
like
I,
said,
take
a
closer
look
at
the
documentation.
We're
also
like
I,
said
earlier.
A
Facilitating
the
existing
experience
at
this
point-
and
we
also
saw
this
with
our
research-
is
that
the
learn
ability
aspect
was
very
strong.
We
saw
that
all
users
that
we
tested
understood
like
oh
okay-
this
is
how
it's
it's
gonna,
be
added,
it's
it's
through
here,
it's
through
and
and
they
would
would
dive
into
the
documentation
a
little
bit
more,
but
we
also
want
to
surface
something
that,
while
this
is
configured
to
the
default
branch,
all
subsequent
feature
branches
will
include
the
skin.
A
A
The
problem
that
we're
looking
at
here
is
it's
not
just
as
simple
as
adding
a
template
which,
which
also
there's
an
include
there
for
for
these
two,
but
it's
for
tasks.
We
also
need
the
user
to
designate
which
URL
is
going
to
be
scanned
and
for
container
scanning.
We
need
them
to
confirm
the
docker
image.
A
The
system
does
a
few
things
that
are
a
little
bit
different
than
the
other
flow.
It
adds
the
selected
template
and
variables
to
the
gate
lab
animal
file.
We'll
take
a
look
at
that
in
the
minute
the
commit
it's
also
a
CI
skip
commit
and
the
therefore
the
pipeline
would
be
skipped
and
yeah.
Then
the
merge
request
is
created
with
the
changes.
A
Okay,
we
see
here
we're
still
leveraging
the
documentation
in
here,
although
it's
a
little
bit
more
extensive
for
DES
and
container
scanning
and
we're
really
surfacing
those
key
variables
that
are
needed.
So,
in
the
case
of
SAS,
we,
where
we're
telling
them
additional
configuration,
is
required
and
here's
why
link
to
the
documentation,
there's
certainly
other
variables
that
could
be
needed,
but
this
is
the
one
that
needs
to
be
committed
to
avoid
a
failed
pipeline
and
container
scanning.
A
The
user
just
needs
to
confirm
that
this
is
indeed
the
docker
image
name
and,
and
so
we're
leveraging
our
documentation
and
and
also
surfacing
that
they
need
to
add
this
so
based
on
what
we
saw
with
user
studies,
the
learnability
aspect,
this
is
gonna,
help
facilitate
that
and
I
think
that
they
could
understand
from
here
what
the
additional
requirements
are
with
the
Skip
CI
and
WIP
work
in
progress.
That's
additionally
helping
us
and
it's
it's
letting
them
know
that
this
is
an
incomplete,
merge,
request
and
here's.
A
Why,
in
this
documentation,
certainly
I
think
that
this
is
an
area
which
would
be
great
for
feedback
is
how
to
make
this
documentation
that
we're
surfacing
Crystal,
Creek,
clear
and
crisp
to
the
user,
but
we're
using
really
the
work
in
progress
and
the
Skip
CI
to
to
make
it
very
clear
that
additional
requirements
are
needed.
I
just
want
to
scroll
down
and
just
show
it
it
will
operate
just
like
any
skip,
CI
or
or
the
work-in-progress.
A
The
experience,
though,
would
just
reinforce
that
if
the
user
jumped
over
to
changes
just
zoom
in
on
this
a
little
bit,
we
can
continue
to
leverage
our
documentation
directly
in
the
additional
commits
that
were
added.
So
in
this
case,
let's
say
that
there
was
include
here.
We
have
these
certain
templates
if
they
were
added,
and
then
we
have
the
variables
down
here.
These
are
the
two
variables
that
we're
kind
of
focusing
on
for
container
scanning.
A
It's
confirming
this
image
tag,
and
so
what
we
have
here
is
just
confirm
image
tag
its
blanked
out
and
it
has
the
link
to
the
documentation.
So
when
they
do
come
here
and
take
a
look
at
the
changes
that
were
made,
we
can
surface
this
directly
to
them
here.
So,
for
example,
with
with
the
URL
that
we
need,
it
has
kind
of
a
to-do,
and
this
is
the
URL
website
to
be
scanned.
So
it's
learning
that
this
is
the
case
for
a
desk
and,
of
course,
here's
our
documentation.
A
Ok,
so
I
just
want
to
jump
to
one
other
area,
that's
kind
of
related
to
configuration,
another
flow
that
we
will
soon
see
on
the
dashboard.
It's
not
yet
there,
but
here
on
the
group
dashboard,
we
actually
show
it
a
group
level
or
will
show
what
projects
in
there
are
not
being
tested
and
what
projects
are
out
of
date.
For
this
we're
focusing
on
the
projects
that
are
untested
if
they
are
untested.
That
means
that
there
are
no
analyzers
that
have
been
applied
to
that
project,
and
so
we're
surfacing
this
at
the
group
level.
A
Otherwise,
the
user
would
have
to
go
project
a
project
to
figure
that
out.
So
this
aims
to
help
that
from
here
they
could
click
an
untested
project
which
they
do
here
and
that
will
bring
them
to
the
configuration
page
then
from
there.
If
they
wanted
to
configure
it
in
a
certain
way,
they
could,
with
the
flows
that
we
just
took
a
look
at
in
the
current
state,
they
would
have
to
either
just
go
to
the
main
documentation
page
and
take
a
look
at
what's
needed
for
each
of
them
individually.
A
A
Well,
that's
the
latest
iteration
really
appreciate
you
watching
I
think
I
from
a
UX
standpoint,
we'd
love
some
feedback
on
these
different
flows,
especially
the
ones
pertaining
to
dash
and
container
scanning.
One
thing
I
can
add
to
this
is
down
the
road.
There
could
be
a
an
input
box,
or
something
like
that
here
on
this
screen
to
add
that
URL.
But
this
is
in
the
spirit
of
iteration.
A
How
can
we
keep
this
small
or
as
small
as
possible
and
there's
a
lot
of
different
variables
that
could
be
added
to
each
of
these,
and
you
know
we're
trying
to
do
that
outside
of
the
user
interface
for
this
iteration,
or
at
least
that's
what
this
proposal
is
about.
So
another
great
area
for
feedback
would
be
what
is
the
type
of
specific
copy
and
documentation
that
we
want
to
have
here.