►
From YouTube: UX Showcase: SAST Configuration UI
Description
Becka Lippert, Product Designer of the Static Analysis group within the Secure & Defend stage at GitLab, walks through the initiative to bring SAST Configuration into the UI for a more seamless workflow and improved user experience.
A
Lipper
and
I'm
a
product
designer
on
the
secure
team,
and
today
I'm
going
to
be
talking
about
sas
configuration
ui
so
first
off
what
is
sast
sas
stands
for
static
application,
security
testing
and
it's
one
of
the
many
security
controls
available
through
get
lab
security
offerings
sas
analyzes
your
source
code
for
vulnerabilities,
so
git
lab
checks.
The
sas
report
and
compares
the
found
vulnerabilities
between
the
source
and
target
branches
when
a
pipeline
runs
so
an
example.
A
So
the
problems
that
we
were
specifically
trying
to
solve
with
the
sas
configuration
ui
initiative
breaks
down
into
two
parts.
The
first
is
enabling
so
previously
the
security
and
compliance
configuration
page
had
a
link
to
the
documentation
where
the
user
would
have
to
go
back
and
forth
to
gitlab.com
manually
following
directions
and
copy
and
pasting
commands
in
order
to
enable
sas.
The
second
part
is
configuring.
A
Previously,
users
could
only
configure
sast
in
order
to
get
more
accurate
results
by
locating
and
editing
the
sas
gitlab
ci
yaml
file
to
complicate
things
a
little
bit
further.
If
a
user
has
auto
devops
on
this
file
isn't
exposed
at
all
and
I'll
walk
you
through
that
in
a
bit.
So
even
when
the
user
can
access
this
yaml
file,
we're
unable
to
offer
any
kind
of
information
about
each
variable
guidelines
or
parameters
we
suggest
staying
within
or
any
logic
checks
or
dependencies
with
regard
to
how
the
variables
interact
with
each
other.
A
So
in
a
nutshell,
it's
a
lawless
land,
the
wild
west
of
configuration
and
we're
turning
it
into
more
of
a
civilized
society.
If
you
will
okay.
So
let's
look
more
closely
at
enabling
the
image
here
on
the
left
is
what
our
configuration
page
looked
like
prior
to
any
con
sas
configuration
ui
work.
You
can
see
the
security
and
controls
we
have
sas,
in
addition
to
dash
dependency,
scanning,
container
scanning,
etc
and
the
status
column
on
the
right.
So
you
can
see.
None
of
these
are
yet
enabled
on
the
right.
A
A
A
However,
on
the
right,
we
have
the
sas
configuration
ui,
which
is
where
you
go
after.
You
click
that
enable
button
that
we
saw
on
the
last
page
and
so
from
there.
We
can
offer
more
of
a
step-by-step
flow
in
a
form
layout
that
provides
more
context
about
each
variable
and
guidelines.
If
we
have
any.
This
comes
pre-configured
with
our
recommendations,
but
the
user
can
change
them
if
they'd
like
to
so
now,
let's
do
a
demo.
A
A
So,
let's
conf,
let's
enable
sash
the
old
way
first
and
pretend
that
enable
button
isn't
there,
so
I
would
have
to
go
into
files.
I
can
see
here
that
there
is
a
gitlab
ci
yaml
file.
If
I
click
into
here,
we
can
see
that
sas
the
sas
template
is
included,
but
we
can't
actually
configure
those
variables
because
it's
a
template
include-
and
these
variables
aren't
exposed
here.
A
A
A
If
I
wanted
to
change
anything
like
the
the
stage
that
sast
runs
in,
I
could
do
that
and
then
click
commit
changes
and
then
a
pipeline
would
run,
and
hopefully
that
would
be
that
would
go
through
successfully
without
errors,
so
that
is
the
old
way
of
doing
it.
Now,
let's
look
at
what
this
looks
like
from
within
the
configuration
page,
if
I
click
on
enable
I'm
seeing
these
variables
in
here.
For
me,
this
is
our
mvc,
so
there's
a
lot
more
to
come.
A
We
also
have
a
link
to
a
feedback
issue
up
here,
but
essentially
we're
providing
some
guidance
here
on
what
these
variables
are,
and
this
will
continue
to
iterate.
We
could
have
different
kind
of
input,
controls
like
steppers
and
offer
error
message,
and
things
like
that.
If
something's
not
looking
right
so
from
here,
we
can
create
a
merge
request
and
submit
the
merge
request.
So
those
are
the
those
are
the
changes
that
we've
made.
So
let's
break
this
down
a
little
bit
more.
A
A
One,
the
reddish
orange
section
at
the
top
is
the
get
lab
layer
configuration
so
get
lab,
takes
the
12
or
so
open
source
analyzers
that
go
into
our
sass
offering
and
applies
a
wrap
around
for
it
for
consistent
results.
For
example,
each
analyzer
has
their
own
criteria
for
severity,
critical,
high,
etc,
and
some
have
no
severities
at
all.
So
when
we
show
results
from
all
of
our
scanners,
sas
das
dependency
scanning,
etc,
we
want
critical
to
mean
the
same
thing
across
the
board.
A
Now.
The
second
section
is
the
individual
analyzer
layer
configuration
so
each
analyzer
works
on
a
different
language,
bandit
for
python,
breakman,
for
ruby
on
rails,
etc.
When
a
pipeline
runs,
sas
automatically
identifies
the
language
used
in
the
file
trying
to
be
merged
and
those
analyzers
go
to
work
scanning
for
potential
vulnerabilities.
A
A
So
what
are
some
of
those
those
variables?
Look
like
one
example
from
the
gitlab
layer
is
excluded
paths,
so
any
vulnerabilities
found
in
these
paths
will
be
excluded
from
the
generated
output,
and
this
is
helpful
for
developers
who
want
to
reduce
noise
from
the
list
of
vulnerabilities
found,
for
example,
in
a
test
directory
which
might
have
intentional
problems
like
developers,
tooling
or
scripts,
and
things
that
won't
get
deployed
into
a
production
instance
and
thus
pose
no
risk.
A
One
of
the
examples
in
the
analyzer
section.
If
we
look
at
flaw,
finder
flaw:
finder
looks
for
vulnerabilities
in
c
and
c
plus
plus
source
code,
which
can
be
configured
to
ignore
vulnerabilities
under
a
set
risk
level.
So
by
default
we
set
this
at
1,
meaning
that
we
only
ignore
vulnerabilities
that
flawfinder
identifies
as
no
risk,
but
some
projects
may
have
less
vulnerable
data
in
it,
in
which
case
a
user
may
only
care
about
the
highest
risk
vulnerability.
So
they
may
want
to
set
this
to
a
three
or
even
a
four.
A
A
A
Almost
all
of
the
participants
have
to
contact
their
tools,
support
team
to
configure
on
their
behalf,
which
adds
friction
and
lag
time
to
the
process,
whereas
we're
putting
the
we're
giving
the
power
directly
to
the
user
themselves,
and
this
is
a
list
of
our
finalized
jobs
to
be
done.
That
came
out
of
that
research
initiative.
A
You
can
see
that
three
of
them,
two
primary
and
three
sorry,
five
of
them,
two
primary
three
secondary
applied
to
configuration
so
the
first
one
in
primary
in
purple.
Third,
one
down
when
I
want
to
get
the
most
relevant
findings
from
my
scanner.
I
want
to
tune
it
in
a
way
that
works
best
for
our
org,
so
that
we
don't
waste
any
time
sorting
through
false
positives
or
unimportant
findings.
A
The
next
one
is
when
I
start
when
I
want
to
start
incorporating
security
into
my
org,
I
want
to
integrate
it
seamlessly
into
my
existing
workflow.
So
there's
more
likelihood
it
will
be
used
and
without
disruption,
and
then
next
we
have
when
I've
tuned
my
scanner.
I
want
to
feel
confident
that
it
works
properly.
So
I
don't
worry
that
I
broke
something
and
that
it
will
compromise
the
application
security.