►
From YouTube: UX Showcase: Group-level security scanner status widget
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Cool
so
I'm
becca
lipper
and
I'm
the
product
designer
for
static
analysis,
which
is
under
the
umbrella
of
secure
and
protect,
and
today
I
am
going
over
the
group
level
security
scanner
status,
widget
that
we
just
wrapped
up
designed
for.
So
I
wanted
to
start
with
the
problem
that
we're
solving
here.
A
So
this
is
sam,
he's
a
security
engineer
and
he's
responsible
for
making
sure
that
most
of
the
applications
at
his
company
are
using
security
scanning
in
order
to
keep
the
company
data
and
the
data
of
their
customers
safe.
So
let's
look
at
what
sam
has
to
do
with
the
current
gitlab
functionality
in
order
to
make
sure
that
security
scans
are
being
run
on
all
projects
in
a
given
group.
A
So
I
have
a
demo
group
here
and,
as
we
all
know,
there
can
be.
You
know
hundreds
of
projects
in
a
group
here
we're
just
dealing
with
a
subgroup
that
has
five
projects
and
you'll
see
that
even
with
five
projects,
it's
still
a
little
bit
painful.
A
A
So
he
may
think
that
he
could
come
into
security
and
compliance
and
get
this
information
on
the
dashboard.
However,
he
can't
the
information
that's
shown
here
is
vulnerabilities
over
time
to
see
if
things
are
trending
in
the
right
direction.
Obviously,
you'd
want
critical
high
to
be
trending
down,
if
not
all
of
them
over
30,
60
and
90
days,
and
then
we
have
the
project
security
status
in
terms
of
grades.
A
This
project
has
a
high
vulnerability
open,
so
it's
currently
in
the
d
column,
however,
there's
no
way
to
see
the
whether
the
scanners
have
been
enabled
or
not.
This
is
just
showing
vulnerabilities
that
are
present
from
the
scanners
that
are
enabled,
but
not
which
aren't
enabled
so
another.
So
really,
the
only
way
of
confirming
whether
or
not
a
project
has
security
scanners
enabled
is
to
go
into
each
of
these
projects.
A
Even
then,
it's
a
little
bit
tricky.
So
let's
go
into
this
project,
for
example,
there's
kind
of
two
ways
of
accomplishing
this,
so
the
first
one
would
be
to
go
into
pipelines
and
look
for
we'll
use
sas.
As
an
example,
we
could
use
das
container
scanning,
license
compliance
fuzzing
et
cetera,
but
let's
use
sas
as
an
example.
A
A
A
A
So
you
know
I
can
see,
maybe
that
gosek
is
running
successfully,
but
in
terms
of
the
other
13
analyzers.
That's
that's
a
little
bit,
that's
even
more
work.
So
what
happens?
If
we
go
into
the
security
and
compliance
area,
we
can
go
down
to
configuration
and
see
that
which
scanners
are
enabled
or
not
enabled
across
the
project.
A
A
So
if
the
latest
pipeline
had
a
failure
for
sas,
let's
say
the
sas
job
or
jobs
of
that
pipeline
had
any
errors
or
didn't
run
successfully.
For
some
reason,
this
enabled
would
switch
to
not
enabled
so,
even
though
the
yaml
the
sas
yaml
file
is
present
in
the
project,
it
switches
to
not
enabled
there's
a
very
large
conversation
taking
place
about
this,
but
essentially
it
boils
down
to
this.
So
I'll
go
into
it
a
little
bit
more
here
and
I
can
link
to
issues
where
this
is
an
ongoing
conversation
as
well.
A
A
We
went
the
pipeline
or
jobs
page
route,
where
you
control
f
for
sas
to
click
on
the
pipeline
and
then
try
to
figure
out
if
the
sas
job
ran
successfully.
You
also
have
to
know
that
the
sas
job
is
under
the
test
stage,
so
that's
like
another
click
and
then
more
cognitive
wheels.
Turning,
alternatively,
you
could
go
to
the
project's
security
configuration
page
if
the
scan
type
says
enabled
that's
a
confirmation
that
the
scanner
is
running
successfully.
A
However,
if
it
says
not
enabled,
as
I
mentioned
before,
this
can
mean
one
of
two
things:
either
one
the
sassy
ammo
file
does
not
exist
in
that
project
and
the
call
to
action
there
would
be
to
add
the
sassy
ml
file
if
sam
said
his
name,
yeah
sam
wanted,
wants
sas
to
be
on
running
on
that
project.
A
A
A
Solution
that
can
come
from
this.
That
is,
is
running
in
parallel,
that
I
have
an
issue
open
for
where
maybe
we
can
say.
Yes,
the
file
is
present,
but
there
were
some
detected
errors
that
you
may
want
to
look
into
versus.
A
There
is
no
sas
dml
file
at
all,
so
there's
some
conversations
about
that
as
well,
but
it's
important
to
understand
for
the
purpose
of
this
widget,
the
technical
constraints
that
we
currently
do
have
towards
the
end
of
this
I'll
show
the
mvc
and
then
the
post
mvc
that
addresses
all
of
this
complexity,
and
I'm
sure
people
have
a
lot
of
questions.
So
we
can.
A
We
can
definitely
answer
those
at
the
end
too,
since
we
have
plenty
of
time
here
so
the
after
flow
I'm
going
to
walk
through
this
and
then
I'll
do
a
demo
in
a
prototype
of
what
this
looks
like.
So
we
went
through
the
before
flow,
and
now
the
after
flow
will
be.
The
user
goes
to
git
lab,
they
select
a
group,
they
click
on
security
and
compliance
in
the
navigation.
A
They're
then,
on
the
group
level,
security
dashboard
and
it
defaults
to
an
overview
tab.
They
would
click
on
the
scan
status,
tab
and
see
the
security
scanner
status.
Widget
what's
happening
on
the
back
end
system
is
looking
for
the
most
recent
security
job
on
a
completed
pipeline
for
each
project
in
the
group
it
pulls
in
the
project
name
the
relative
date
of
when
it
ran
the
pipeline
status
and
each
security
job
result.
A
With
this
information,
the
user
can
click
on
the
project
name,
which
would
take
them
to
that
configuration
page
where
they
could
enable
sas.
If
it's
not
enabled,
for
example,
they
could
also
click
on
the
pipeline
number
or
the
pipeline
badge,
and
this
would
take
them
to
the
pipeline
page.
If
it's
a
failed
pipeline,
for
example,
they
may
want
to
look
into
why
it
failed.
A
They
could
click
on
a
failed
status,
job
icon,
which
would
take
them
to
the
pipeline
page
and,
more
specifically,
the
failed
jobs
tab
of
that
pipeline
page.
So
they
can
look
into
the
failed
job
and
why
it
failed
and
troubleshoot
that
or
they
could
click
on
a
job
with
the
other
statuses
of
success,
passed
with
warnings
or
skipped,
and
that
would
take
them
to
the
pipeline
page
as
well.
So,
let's
see
what
this
looks
like,
I
just
deleted
that
that's
not
what
I
wanted.
A
So
this
prototype
by
the
way
starts
at
this
group
level:
security
dashboard.
So
by
this
point,
user
has
come
to
git,
lab
and
selected
a
group
and
then
they've
navigated
to
the
security
and
compliance
area
of
the
navigation.
So
this
is
what
they're
currently
seeing
those
dashboard
widgets
that
we
looked
at
earlier.
You
can
see
they've
been.
A
Developed
a
little
bit
further.
This
is
also
a
little
bit
of
a
future
state.
There's
development
working
on
this
right
now
to
expand
the
functionality
and
usability
of
those
tables
as
well.
So
what
we've
added
up
top
is
the
scan
status
widget
here.
The
reason
we're
putting
this
on
a
new
tab
is
because
these
widgets
here
will
all
fall
under
a
page
wide
or
a
tab
wide.
A
I
guess
filter
and
we
wanted
to
be
able
to
customize
different
filters
for
the
security
scan
status,
widget,
so
user
would
click
on
scan
status
and
then
they'd
be
able
to
see
all
of
the
projects
in
the
group
and
the
latest
completed
pipeline
run
on
the
default
branch
of
each
project,
with
where
at
least
one
security
job
ran
or
tried
to
run.
So
you
can
see
for
project
a
this
pipeline
failed
five
minutes
ago,
and
here
are
the
the
job
results.
A
So
it's
essentially
that
pipeline
page
but
filtered
down
to
a
security
perspective
which
our
persona
sam,
the
security
engineer,
security
analyst.
They
have
a
number
of
different
titles.
This
is
really
what
he
cares
most
about
so
from
here
I
can
see.
A
A
A
I
can
also
click
on
the
pipeline
failed
and
look
into.
Maybe
why
this
failed.
I
can
also
click
on
the
project
name,
and
this
would,
let
me
see
you
know
within
within
the
restrictions
that
we
have
what's
listed
as
enabled
or
not
enabled
for
each
scan
type.
I
can
also
from
this
page
apply
filters.
So
let's
say
that
I
only
want
to
see
where
sas
jobs
failed,
I
can
say
sassed
and
then
or
worse,
asked
didn't
run
okay.
I
just
realized
that
I,
let's
pretend
this
says,
sas
failed.
A
I
prototyped
up
the
wrong
thing.
So
if
this
says
sassed
scan
status
failed,
then
it
would
only
filter
by
the
projects
where
a
sas
job
failed.
You
could
do
the
same
thing
for
not
found
and
that's
essentially
it's
a
bit
of
a
workaround
to
see
where
sas
isn't
enabled,
but
there
could
also
be
other
reasons
for
sas
not
being
found
it's
possible
that
sas
is
enabled,
but
it
didn't
run
on
that
latest
pipeline.
A
For
example,
if
it's
a
dashed
on-demand
scan,
it
is
possible
that
sas
wouldn't
show
up
in
that
pipeline
run,
but
sas
is
enabled
so
there's
a
lot
of
tricky
what
ifs
in
this
whole
situation
as
you're
seeing,
but
we
did
do
solution,
validation
on
this
in
user
testing,
and
we
do
have
a
number
of
customers
currently
who
have
asked
for
this
and
have
actually
used
our
apis
to
come
up
with
tables
of
their
own,
essentially
showing
this
information.
A
So
this
is
what
we
have
for
mvc.
We
are
looking
past
mvc
into
something
a
little
bit
more
ideal
where
we
would
have.
Let
me
try
to
zoom
in
a
little
bit
on
this
one.
A
So
where
we
would
have,
I
knew
that
was
gonna
happen.
That's
just
gonna
be
like
that.
So
we
do,
we
would
be
able
to
see
the
scanner
status
and
it's
either
on
or
off
enabled
or
not
enabled.
So
that's,
essentially
you
know,
does
that
fast
yeml
file
exist.
Does
that
dastyaml
file
exist
and
then
separate
out
any
errors
on
those
jobs
under
that
scan
type
separately,
something
else
that
could
be
really
cool
and
valuable
in
this
post.
Mvc
version
is,
we
are
introducing
a
policies
page
soon
where
users
can
specify.
You
know.
A
I
want
sas
to
run
at
least
once
a
month
at
least
once
a
week,
and
if
that
policy
is
violated,
we
could
call
that
out
in
this
widget,
so
you
might
be
able
to
see
under
last
scan
here,
which
is
maybe
something
that
we
default
to
to
the
we
default
the
sort
by
to
last
scan
so
that
these
badges
would
show
up
at
the
top.
You
can
see
it
says
one
month
overdue,
one
week
overdue,
and
so
that's
basically
saying
hey.
There's
a
policy
set
sas.
A
In
addition,
we
could
list
the
vulnerabilities
currently
open
for
that
project
and
so
that's
a
little
bit
more
future
state,
but
we
wanted
to
get
out
the
mvc
with
what
we
currently
have
so
I've
linked
to
the
mvc
issue
and
the
post
mvc
issue
in
the
ux
showcase
agenda
and
they're
also
at
the
bottom,
in
the
presenter
notes
of
these
slides.
So
that's
what
I
have
for
you.
Does
anyone
have
any
questions.
C
I
do
I'll
start
with
a
thank
you.
I
love
thank
you
for
doing
this
live
first
of
all
sure,
and
then
also
you
did
an
excellent
job
of
setting
us
up
by
building
our
empathy
for
this
user,
so
really
nice
job
on
that
cool.
Now
I
just
have
some
tactical
design
questions.
Can
you
talk
about
why
we've
put
scan
status
on
its
own
tab
and
do
you
have
any
concerns
about
discoverability
of
hiding
what
seems
like
very
important
information
behind
kind
of
dashboard
view
that
doesn't
honestly
have.
A
A
whole
lot
on
it
right
now
sure
yeah
so
andy,
I
know,
has
a
number
of
widgets
he's
got
a
huge
vision
for
what
that
security
dashboard
will
look
like.
He
has
a
lot
of
designs
in
the
backlog
that
I
think
the
the
team
is
trying
to
get
to
frantically
right
now.
So
this
is.
A
A
snapshot
of
what
the
future
of
this
page
will
look
like,
hopefully
in
the
near
future,
but
the
there
will
be
more
widgets
added
to
this
page
and
essentially
the
vulnerability.
A
What
is
their
name
of
that
group?
Threat,
insights
or
vulnerability?
A
I'm
blanking
on
the
other
name
right
now,
but
it's
matt
and
matt
wilson
is
the
pm
and
andy
is
the
designer
that
he
works
with.
They
wanted
to
be
able
to
put
widgets
on
this
page
that
all
apply
to
this
filter
at
the
top.
A
So
I
did
originally
propose
to
put
the
security
scan
status
widget
on
this
main
page
they're,
the
ones
that
really
pushed
for
putting
it
on
a
new
tab
because
they
wanted
to.
They
have
a
vision
for
the
widgets
that
go
onto
this
page
and
we
couldn't
figure
out
a
way
to
allow
for
new
filters
only
for
one
widget
without
that
feeling
kind
of
clunky,
because
they
want
to
put
filters
at
the
top
of
this
page
that
apply
to
every
widget
that
they're
adding.
Does
that
make
sense.
C
Yeah,
thank
you.
That
was
a
very
thoughtful
answer
from
you.
Something
I'd
be
thinking
about.
Is
you
know
it's
gonna
take
us
time
to
get
to
this
view
and
I'd
be
thinking
about
whether
well
do
we
start
with
everything
on
one
screen
and
then,
as
we
add
widgets,
maybe
we
break
it
off
into
its
own
tab
and
then
people,
users
already
know
that
it
exists
or
maybe
more
likely
to
actually
look
for
it.
So
this
would
be
some
of
the
things
I'd
be
thinking
through,
but
obviously
I
don't
know
the
answer.
A
Yeah
yeah,
I
know,
and
I
mean
it,
it
does
kind
of
touch
on
a
larger
conversation
about
like
discoverability
of
new
features.
I
know
that
there's
been
some
discussions
in
the
ux
department
about
you
know.
Are
we
doing
a
little
indicator
dot,
calling
attention
to
new
areas
of
the
ui?
Do
we
add
a
banner
at
the
top
of
this
page,
saying:
hey,
there's
a
new.
You
know
tab.
You
should
go
check
out
this
new
widget
in
the
new
tab.
I
think
there
there
are
some
possibilities.
A
There
release
posts.
You
know
things
like
that.
But
yeah
I
mean
it's.
It's
definitely
a
good
conversation.
I
know
that
there's
been
some
there's
been
some
discoverability
issues
when
it
comes
to
those
tabs
as
well.
A
So
it's
it's
definitely
something
that
we
should
consider,
and
I
could
also
do
solution
validation
on
that
and
see
if
people
notice
the
the
tab,
because
when
I
did
do
solution,
validation
on
the
widget,
it
was
just
on
the
widget
itself
and
it
wasn't
on
discoverability
from
this
page
and
having
to
click
into
a
new
tab.
So
that
is
something
I
will
include
as
part
of
the
post
mvc
I'll
make
sure
that
that
discoverability
is
there
and
then
we
can
revisit
that
conversation.
C
You're
you're,
causing
me
to
take
an
even
more
critical
look
at
the
visual
design,
and
you
didn't
say
this
directly
but
kind
of
hinted
around
it.
The
design
of
our
tabs
is
visually,
really
really
muted
and
it
kind
of
almost
runs
into
our
header,
because
it's
just
it's
like
there's
text
and
then
there's
little
text,
but
that's
actually
really
important
text
and
there's
really
not
a
whole
lot
of
visual
distinction
there,
and
so
maybe
that's
something
we
should
be
thinking
about.
C
A
Oh
sorry,
this
just
may
be
a
prototype
limitation.
There
would
be
20
projects
per
page
and
then
there's
a
scrollable
area
if
it
goes
past
20
there's
a
stepper
at
the
bottom,
so
I
have
this
all
broken
down
in
the
figma
file,
which
is
in
the
issue.
A
This
is
my
sigma
link
to
the
design
handoff
and
then
I
copy
and
pasted
a
lot
of
the
the
images
in
here
as
well.
So
we
have
tab
two
with
pagination,
so
this
area
is
scrollable
expanded.
It
essentially
looks
like
this,
so
there
are
20
projects
per
page
and
then,
if
there's
more
than
20,
there
would
be
pagination
at
the
bottom.
C
B
A
B
That
are
failing,
but
I'm
not,
I
didn't
understand
very
well.
Maybe
you
talked
about
this.
What
what
security
analysts
are
looking
for,
because
for
me
as
someone
who
doesn't
who's
not
very
familiar
with
this,
I
look
at
this
table
with
a
lot
of
with
a
lot
of
icons,
red,
green,
yellow,
and
I
don't
know
what
to
look
for
I
mean
I
see
that
some
things
are
failing.
Do
I
need
to
to
fix
the
failing
pipelines
or
the
failing
jobs
or.
B
A
Yeah
I
mean
like
I
said
I
mean
I
think
this
goes
back
to
I
mean
this
is
very
much
an
mvc.
We
have
talked
to
some
customers
who
who
have
taken
our
api
data
and
created
a
table
like
this,
and
they
said
even
this
suffices.
We
just
want
to
see
what's
running
and
if
it's
running
you
know
what's
running
successfully
or
not
so
just
to
even
be
able
to
see
that
you
know.
A
Ideally,
if
I'm
sam
and
I
want
all
of
the
security
scan
types
enabled
across
all
of
my
projects,
I
want
to
see
all
green
check
marks
across
this
whole
table.
So
anything,
that's
a
lack
of
an
icon
or
an
icon
that
is
not
a
green
check.
Mark
essentially
is,
is
going
to
be
a
call
to
action
for
me
right.
B
So
would
would
it
be
able
to
surface
that
like
if,
if
there's
just
even
one
failing
job
surface,
that
more
clearly
and
and
de-emphasize
all
of
the
other
projects
that
are
not
that
are
working
well
and
maybe
again
in
the
overview
tab
like
saying
hey,
you
have
one
project
where
there's
there
are
failing
tests,
go
look
at
this.
A
A
You
can
set
some
jobs
to
cause
the
pipeline
to
fail,
but
sometimes
you
can
allow
for
failure
as
well.
I
know
camellia
has
worked
on
some.
C
A
Issues
there
there's
a
lot
of
complexity
within
here
that
I
didn't
want
to
try
to
address
all
of
the
things.
I
know
something
else
that
we
will
often
hear
as
well
is
green
check,
mark
some
people
who
are
less
familiar
with
security
in
a
ci
cd
setting
where
it's
pipeline
based.
They
think
that
green
check
marks
mean
everything.
A
B
That's
a
very
that's
a
very
interesting
finding.
I
I
I
would
assume
that
maybe
for
security,
you
would
have
to
switch
that
around
and
prioritize
showing
like
jobs,
failed
or
jobs
have
resulted
in
these
vulnerabilities
and
not
so
much
like
it
passed
or
not
because
it
can
induce
in
error.
B
So
I
think
that's
that's
something
that
would
be
very
interesting
is
to
change
how
we
display
this
information
and
not
so
much
from
a
pipeline
standpoint,
because
it's
not
very
useful.
It's
more
useful
to
know
like
the
pipeline
fails
or
the
pipeline
produce
these
vulnerabilities.
If
everything
is
working,
we
don't
need
to
to
talk
much
about
it.
B
So
I
think
my
comment
is
more
for
thoughts
about
how
like
we're,
giving
this
amazing
information
and
there's
a
lot
of
useful
information
here,
but
I
don't
think
we're
doing
a
good
service
to
the
user
to
emphasize
or
highlight
what
they
need
to
do,
because
there
are
the
tools
there.
You
you
added
those
filters
at
the
top,
which
are
very
useful,
but
the
user
needs
to
do
that
work.
B
A
C
I
think
it'd
be
interesting
to
see
pedro
and
becca
have
a
quick
working
session
where
they
just
maybe
went
through
some
quick
ideations
sketch
them
out
because
pedro
I
can.
I
can
see
where
your
brain
is
heading
and
if
you
were
able
to
draw
it
out
a
little
bit
for
becca,
she
might
go.
Oh
okay
and
then
she's
got
all
of
this
tactical
knowledge
around
what
our
technical
limitations
are,
that
might
really
uplevel
the
design,
but
within
the
constraints
of
an
mvc
in
our
current
technical
limitations,.
A
A
Those
vulnerabilities
are
also
being
surfaced
in
every
mr,
where
you
know
we're,
especially
if
there's
security
approvals
enabled
that
essentially
will
block
the
mr
from
being
merged
without
a
security
approver
coming
in
and
making
sure
that
those
vulnerabilities
are
triaged
or
you
know
that
they
can
be
dismissed
because
they're
actually
low
risk
so
yeah.
I
the
way
that
we've
been
thinking
about
this
is
this
is
not
vulnerabilities
detected.
A
This
is,
are
things
working
as
they
should
be
and
then
dealing
with
vulnerabilities
later
right,
because
I
mean
you
could
look
at
the
vulnerability
report
which
has
the
list
of
current
vulnerabilities
open
on
the
project
and
that's
also
a
little
bit
of
a
confusing
emotional
mixtape,
because
if
that's
at
zero
and
there's
no
vulnerabilities,
that
could
be
a
great
thing.
That
could
mean
that
only
secure
code
is
being
shipped
and
the
developers
are
doing
their
due
diligence
to
make
sure
that
there's
no
loopholes
in
the
code
at
all.
A
There's
no,
you
know
secrets
secret
detection
is
running
and
it's
not
picking
up
any
potential
secrets
and
or
that
you
know,
maybe
there
were
a
couple
of
vulnerabilities,
but
they
were
all
triaged
and
patched.
A
However,
it
could
also
mean
that
an
empty
state
on
the
vulnerability
report
could
mean
that
security
scans
just
aren't
running,
and
so
it's
not
necessarily
a
good
thing
or
that
they're
enabled,
but
the
configuration
of
the
scanner
got
so
convoluted
and
it
broke
somewhere
along
the
way
because
configure
configuring
security
scans
is
is
a
complex
process,
which
is
something
else
that
we've
tried
to
address
in
fast
with
this
configuration
ui
we're
trying
to
encourage
configuration
within
a.
A
Within
a
from
a
place
where
we
can
like
add
some
logic
for
them
without
the
pipeline
running
and
turning
up
errors,
so
you
know
this
is
mvc
as
well,
but
a
future
state.
If
I
put
something
in
here
and
try
to
configure
one
of
these
variables
and
it
would
break
ideally,
this
system
says
you
know:
hey,
that's
that's
gonna
break
things,
so
my
wheels
are
turning
and
I'm
going
in
a
hundred
different
directions.
Right
now
and
I
I'm
trying
to
get
back
to
the
original
question,
but
everything
kind
of
goes
into
everything
else.
A
A
B
Yeah,
if
you
feel
like
it's,
it's
we're
at
the
right
moments
to
diverge
a
little
bit,
I'm
I'm
open
to
that.
So
it
all
depends
on
the
level
of
confidence
and
where
we're
at,
where
we're
at
in
the
iteration
timeline.
So
yeah.
A
Yeah,
I
think
I
think
at
the
least
we
could
start
to
put
some
ideas
in
this
post
mvc
issue
that
I
have.
A
Or
I
mean,
depending
on
what
comes
out
of
it
if
it's
like
another
widget,
that
could
run
in
parallel
as
the
mvc
issue
as
well.
So,
let's
think
and
see
what
comes
of
it.
D
Yeah,
I
was
just
like
thinking
on
this
kind
of
idea.
I
think
it's
possible
that
we
give
users
some
indication
to
have
like,
overall,
like
pipeline
studies
or
job
studies
on
the
main
dashboard
as
indication
to
check
and
just
elaborate
a
little
bit
on
the
allow
failure,
feature
that
when
user
consciously
turn
it
on
turn
it
off
it's
kind
of
their
choice.
If
they
turn
a
low
failure
on
that
means
they
want
to
they.