►
From YouTube: UX Showcase MR Inline Notifications
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
Hello,
I'm
becca.
I
am
the
product
designer
for
secure
the
under
the
secure
umbrella.
I've
been
the
product
designer
for
static
analysis,
just
as
a
reminder
moving
to
vulnerability
management
in
14
3,
but
all
of
the
groups
under
secure
are
very
much
collaborative
and
so
we'll
continue
to
work
on
this
feature
that
I
am
about
to
show
you
so
we're
going
to
talk
about
mr
inline
findings
and
security
vulnerabilities
in
the
context
of
the
code.
That's
introducing
them.
A
So
a
little
bit
of
a
persona
remix
secure
tends
to
focus
on
sam
the
security
analyst
who's
primarily
responsible
for
keeping
sensitive
applications
safe.
For
this
feature,
we're
focusing
on
sasha
the
software
developer
and
helping
him
review
security
vulnerabilities
that
his
code
introduced.
A
Why
are
we
doing
this?
A
few
reasons?
One
security
analysts
need
help.
It's
unrealistic
to
expect
security
to
triage
all
vulnerabilities
on
their
own,
that
every
developer
across
the
org
is
introducing
also
consider
that
smaller
and
even
medium-sized
teams-
probably
don't
even
have
a
dedicated
security
person,
let
alone
team
I'll
get
into
all
of
that
a
little
bit
more
in
a
second.
A
The
second
reason
why
we're
focusing
on
sasha
the
software
developer
is
developers
understand
the
importance
of
writing
secure
code,
but
their
workflows
aren't
being
supported
currently,
so
I've
spoken
with
a
lot
of
developers
over
the
last
month
and
have
learned
that
they
are
happy
to
triage
vulnerabilities.
They
would
love
to
write.
You
know
secure
code
as
long
as
a
it's
their
code,
that
is
introducing
the
vulnerabilities,
not
someone
else
on
their
team
and
right
now,
with
the
current
implementation.
A
A
So
I
just
want
to
get
into
security.
Analysts
need
help
a
little
bit
more,
I'm
going
to
spend
the
next
couple
of
slides
talking
about
the
the
problem,
because
I
think
it's
really
really
important
to
understand
this
before
we
get
into
the
solution.
So
on
security
analysts
need
help.
A
This
is
from
a
linkedin
course
that
I
recently
completed
called
devsecops
building
a
secure,
continuous
delivery.
Excuse
me-
and
this
was
a
slide
in
it,
but
this
message
is
communicated
through
several
articles.
I've
linked
some
below
in
the
comments,
but
it's
it's
very
typical
to
see
a
ratio
like
this.
You
have
about
100
developers
to
10
operations,
people
to
one
security
person.
A
So
what
does
that
look
like?
In
practice?
All
of
these
developers
are
creating,
mrs.
They
may
be
introducing
one
vulnerability
here:
eight
there
12
over
there
and
that
can
equate
to
hundreds
or
even
thousands
of
vulnerabilities
that
need
to
be
triaged
every
week
by
this
one
person,
it's
not
sustainable.
A
So
what
happens?
Devs
start
to
see
security
as
a
blocker.
So
this
you
have
this
one
security
person
saying
no
merge
until
I
make
sure
it's
safe
and
then
you
have
these
developers
saying.
Oh,
it's
just
a
small
bug
fix
I've
been
waiting
three
days
already
or
come
on
dude
it's
the
last
day
of
the
milestone.
I
need
to
get
this
feature
shipped
like.
Please
just
approve
it
for
now.
A
Like
I'm
sure
it's
fine,
I'm
sure
there's
no
risk,
and
maybe
you
have
an
engineering
manager
saying
that
poor
security
person
I
wish
my
team
was
better
equipped
to
help.
A
So
let's
look
a
little
bit
more
closely
at
the
developer,
workflows
that
aren't
being
supported.
So
this
is
a
typical
developer.
Workflow
for
shipping
code,
a
developer
writes
code
locally.
They
they
then
push
to
gitlab
and
create
an
mr.
They
review
the
proposed
changes
in
the
mr
and
then
request,
reviews
and
approvals
conversations
collaboration
happen
from
there.
Often
there's
changes
to
the
code.
A
They
may
you
know,
run
another
pipeline
and
then
we'll
resolve
threads
errors,
conflicts,
review,
job
findings
and
anything
that
may
be
blocking
the
merge
if
there
are
any
policies
that
as
annabelle
covered,
that
could
be
blocking
the
merge.
Those
have
to
be
handled
before
the
merge
can
proceed
and
then
finally,
you
get
to
merging.
A
So
it's
this
step
where
ideally
developers
would
review
their
own
security
findings
and
looking
at
the
results
from
the
security
jobs
that
have
run,
but
do
they?
No,
they
don't
well.
Why
not
so
there's
a
few
reasons
why
they
don't,
but
for
the
sake
of
brevity
and
to
keep
it
in
context
of
the
future
proposal
ahead,
we're
focused
on
solving
the
following
two
problems.
A
So
the
first
is
that
devs
need
support
along
the
way
and
our
workflows
don't
provide
this
yet
so
devs
will
sometimes
need
to
collaborate
with
other
developers
or
the
security
person
or
team
if
they're
unable
to
triage
the
vulnerability
on
their
own
and
then
two
our
workflows
require
an
added
manual
step
of
going
to
the
security
widget
to
review
vulnerabilities,
in
other
words,
devs
have
to
go
out
of
their
way
and
interrupt
their
preferred
workflow.
To
do
this
so
on.
A
The
right
here
is
a
screenshot
of
our
current
secure
widget
in
the
mr
and
different
companies
may
have
different
policies
as
to
which
severity
vulnerabilities
need
to
be
triaged.
Before
proceeding
with
the
mr,
we
currently
have
a
vulnerability
check,
as
annabelle
also
mentioned
that
can
be
enabled
on
a
project
that
will
block
an
mr
from
proceeding
if
there
are
critical,
high
or
unknown
severity
vulnerabilities
that
have
been
that
have
been
detected
as
part
of
those
secure
jobs
that
ran
in
the
pipeline.
A
So
currently
a
developer
would
have
to
come
into
this
security
widget
and
which
is
currently
divided
by
scan
type.
So
you
have
sas
at
the
top
here.
Dependency
scanning
container
scanning
and
so
forth,
and
they
would
have
to
look
at
the
criticals
under
each
category,
then
the
highs
and
then
the
unknowns
which
are
actually
at
the
bottom,
underneath
medium
low
and
info
severities.
A
So
it's
very
manual,
if
you
click
on
these
vulnerabilities,
a
modal
pops
up
and
there's
not
really
a
workflow
in
there.
You
can
create
an
issue
from
there
or
you
can
dismiss
it,
but
in
terms
of
collaborating
on
that
vulnerability,
pinging
a
person
on
the
security
team
or
another
developer
that
workflow's
just
not
there
yet-
and
this
is
no
fault
to
anyone
on
the
secure
team.
A
Secure
is
a
fairly
new
stage.
It's
been
around
for
what
two
or
three
years
and
the
focus
initially
was
on
breadth
versus
depth,
and
so
now,
what
we're
starting
to
see
is
more
depth
and
building
out
the
quality
of
these
features,
rather
than
just
a
wider
feature
set.
So
this
is
really
exciting
because
we
can
start
to
make
these
things
better.
A
So
the
feature
idea
that
we
had
to
address
these
problems
is
inline
findings
in
the
mr
def.
A
Let
me
just
take
a
look
at
the
time.
Okay,
eight
minutes
a
lot
to
cover
in
eight
minutes,
so
I
will
go
over
this
at
a
high
level.
These
are
the
steps
that
I've
taken
so
far
as
part
of
this
initiative.
A
It
started
with
syncing
and
collaborating
with
the
code
quality
team
which
has
since
moved
under
static
analysis,
but
the
code
quality
team
did
before
they
moved
under
static
analysis.
They
did
a
lot
of
great
work
with
being
able
to,
on
the
back
end,
show
findings
in
line
in
the
mrdiff,
so
we
were
able
to
kind
of
use
the
work
that
they
did
and
just
focus
on
more
of
like
the
front
end
more
of
the
ux,
because
they
did
so
much
great
back
end
work.
A
So
after
syncing
with
them,
I
did
a
competitive
analysis.
There's
a
screenshot
of
it
in
the
top
right
there
and
there's
a
mural
link
below
also
did
some
design
explorations
review
with
the
other
designer
with
other
designers
cross
stage.
Product
managers
incorporated
the
feedback
from
those
reviews
into
the
designs.
Then
I
did
solution
validation
on
v1
of
the
design
explorations
I
came
up
with.
I
wrote
a
research
script
and
chatted
with
nine
developers
or
seven
developers.
A
I
think
two
security
engineers
internally
here
at
git,
lab
synthesized
and
shared
those
insights
and
then
took
the
feedback
and
the
learnings
from
v1
solution,
validation
and
am
currently
in
v2
of
solution
validation.
A
So
with
the
six
minutes
I
have
left
here,
these
were
some
of
the
insights
that
came
from
solution.
Validation,
v1.
The
most
important
thing
here
is
that
nine
out
of
nine
participants
found
in
line
findings
helpful,
which
really
surprised
me,
because
there
is
this
attitude
of
security-
is
just
a
blocker.
So
I
was
not
expecting
all
of
the
developers
that
I
spoke
with
to
say
this
is
awesome.
This
is
helpful.
A
I
am,
I
would
definitely
review
these
vulnerabilities
and-
and
this
is
this
is
something
that
will
make
me
feel
like
I'm
writing
more
secure
code.
So
I
was
really
actually
shocked
at
how
accepted
it
was,
and
not
only
that
people
were
very
excited
about
it
and
then
got
some
other
really
great
feedback
and
they
found
the
interaction
of
expanding
and
collapsing
the
vulnerabilities
intuitive,
and
that
was
largely
because
I
had
I'm
using
kind
of
pre-established
patterns
that
we
already
have.
A
So
I'm
going
to
show
you
the
prototype
but
feel
free
to
go
through
these
insights.
I
also
put
some
notable
quotes
in
here
that
came
out
of
those
conversations
you
can
see
at
the
bottom
here.
General
feedback
on
the
prototype
to
see
this
in
line
in
the
code
would
be
incredibly
helpful.
I
think
it's
a
good
feature,
because
I
spent
a
lot
of
time
looking
at
the
changes,
tab
and
the
more
info,
I
can
clean
without
it
impeding
my
review
the
better,
and
you
can
clearly
point
and
say
this
line
is
introducing
phones.
A
Let's
have
a
discussion
so
now
to
quickly
go
over
the
the
version,
two
prototype
that
I'm
I'm
currently
testing.
So
this
is
essentially
what
what
this
will
look
like.
Well,
I
we
need
to
do
more
validation,
but
this
is
this
is
where
we
are
so
far
so
just
to
review.
If
a
developer,
developer
or
security
analyst
wants
to
review
vulnerabilities,
they
have
to
come
down
to
the
security
widget,
which
gives
kind
of
an
overview
of
how
many
critical,
how
many
high
they
would
expand.
A
A
What
if
we
introduce
kind
of
using
this,
how
it
says
11
unresolved
threads?
What
if
we
do
something
similar
at
the
top
here?
That
says
how
many
inline
findings
there
are.
So
maybe
there
is
an
icon
here
that
says
you
know,
okay,
that
should
say
three
but
three
in-line
security
findings
and
then
one
in-line
code,
quality.
A
Finding
something
I
won't
get
into
right
now
is
that
code
quality
is
because,
even
though
it's
moving
under
static
analysis
because
it
works
like
a
static
analysis
scanner,
the
feedback
that
I
got
from
developers
was
they
are
separate
and
I
don't
see
code
quality
as
a
security
finding.
A
So
that's
been
a
little
bit
tricky
for
me
to
try
to
incorporate
code
quality
in
this
view,
but
also
keep
them
separate,
so
I'm
still
kind
of
working
out
how
exactly
we're
gonna
do
this,
but
this
was
one
idea
that
I
had
to
separate
them
out
like
this
and
then
right
next
to
it
it
says
showing
four
findings.
I
thought
it
was
important
to
say
how
many
findings
were
being
shown,
because
if
you
come
down
into
the
settings
menu
you
can
set
filters
here.
A
So
I
wanted
to
show
that
you
there
may
be
filters
applied
that
aren't
showing
all
of
the
available
inline
findings,
something
else.
I've
gotten
really
great
feedback
on.
Is
you
can
toggle
this
on
and
it's
it
shows
only
the
blockers.
So
if
there
is
that
vulnerability
check
policy
set,
it
would
automatically
apply
those
critical,
high
and
unknowns.
A
For
example-
and
people
seem
very
excited
about
this
so
far
and
then,
as
you
can
see,
it
went
from
showing
four
findings
down
to
three
and
then
okay,
I'm
gonna
go
really
quickly
here.
So
there
are
these
severity
icons
in
the
gutter.
Here
you
can
click
and
it
expands
these.
You
can
click
on
these
one
by
one
to
get
more
of
the
details,
you
can
also
leave
a
comment
here,
as
you
would
in
any
line
of
the
the
code.
A
If
you
want
to
bring
in
other
people
and
have
a
conversation,
something
else
that
came
out
of
v1
was
the
need
to
jump
to
the
next.
I
heard
that
from
a
lot
of
people
that
they
would
want
to
be
able
to
jump
to
the
next
because
they
don't
want
to
have
to
scroll
and
look
for
those
icons.
So
if
you
click
on
this
jump
to
the
next,
it's
going
to
automatically
open
the
first
one
and
from
here
you
can
change
the
status
of
the
vulnerability.
A
You
can
add
a
comment
or
you
can
create
a
separate
issue,
I'm
running
out
of
time
very
quickly,
so
if
we
just
keep
jumping
to
the
next
to
the
next.
This
is
something
that
I
am
still
looking
for
feedback
on,
because
the
challenge
here
is
how
to
communicate
that
not
all
security
findings
can
be
shown
in
line
so
for
sas.
We
can
say
it's
this
line
of
code
that
introduced
this,
but
for
something
like
das,
which
scans
the
entire
url
we're
unable
to
do
that.
A
So
I've
been
playing
around
with
some
ideas
of
how
can
we
let
people
know
that
there
are
more
vulnerabilities
that
they
might
need
to
look
at,
and
there
is
an
open
issue
that
we're
still
experimenting
with
about
adding
a
security
tab
and
maybe
jumping
letting
people
jump
over
to
that
to
look
at
the
the
remainder
of
the
vulnerabilities.
A
So,
in
the
zero
seconds
I
have
left
upcoming
updates,
I'm
looking
at
repurposing
the
comp
copy
link
button
to
create
a
link
to
each
inline
vulnerability,
so
they
can
be
individually
referenced
in
the
comments,
adding
a
step
before
viewing
the
status
drop
down.
I've
received
some
feedback
that
going
straight
to
having
that
drop
down,
doesn't
feel
like
a
state
of
completion.
A
So
I
may
add
a
button
here
to
change
status
and
then,
if
you
click
that,
then
it
would
turn
the
status
into
a
drop
down
and
then
removing
the
synopsis
of
other
vulnerabilities
at
the
end
together,
because
while
an
implementation
such
as
that
might
be
helpful
in
a
security
review
context,
it
would
be
out
of
place
in
other
use
cases
of
the
changing
changes.
Tab
like
just
reviewing
code
changes
or
comments
and
then
trying
to
communicate
that
only
some
vulnerabilities
can
be
shown
in
line.
A
So
in
here.
I
have
remaining
questions
and
considerations
both
in
scope
and
out
of
scope,
and
I
that's
that's
all
that
I
have.
I
have
many
links
in
the
ux
showcase
agenda
and
in
the
comments
section
of
these
slides,
if
you
have
any
questions
or
feedback,
feel
free
to
reach
out
or
comment
in
the
issue
that
I
posted.
The
link
for
in
the
agenda.