►
From YouTube: UX Showcase Secure and Defend Boring Iterations
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
Hey
everyone,
I'm
Kyle
from
the
secure
and
defend
UX
team,
and
today
I
have
a
really
boring
presentation
for
you.
It's
one,
that's
predicated
on
our
iteration
value,
which
aims
to
make
things
as
small
as
possible
and
get
out
the
door
as
quickly
as
we
can
so
given
that
I
wanted
to
use
the
time
today
to
highlight
some
of
those
boring
iterative
solutions
that
we're
getting
out
there.
A
But
first,
let's
talk
about
why
boring
solutions
are
so
important.
Well,
first,
it's
an
asymmetrical
nature
of
approach
that
systematically
provides
improvement.
These
are
essentially
low-cost
experiments
that
migrate
our
hypotheses
to
real-life
volatility
that
is
being
in
the
wild,
since
we're
doing
since
we're
often
designing
under
opacity.
Tinkering
and
small
experiments
are
an
ideal
offense
to
uncertainty,
improving
decision-making
and
managing
risk.
A
The
strategy
promotes
continual
risk-taking,
which
we
do
every
day,
but
in
smaller
doses,
this
decreases
the
risk
exposure
versus
high
risk
exposure
and
costly
endeavors
that
include
many
different
teams,
and
so
that's
time
cost
and
even
for
bigger
solutions.
It
makes
the
feedback
signal
a
little
bit
more
fuzzy
because
there's
just
so
much
more
to
get
feedback
on
okay.
So
the
notable
design
trade-off
is
it
ain't,
always
pretty,
and
usually
it's
glued
together
with
a
bunch
of
bubblegum
and
duct
tape,
but
having
small
experiments
exists
in
the
wild
versus
being
discussed
in
an
issue.
A
What
are
some
roadblocks
to
boring
solutions?
Well,
the
first
is
grand
solutions,
the
opposite
of
boring
solutions,
the
sort
of
arch-nemesis
these
solutions
often
cover
many
small
things,
but
can
block
the
shipping
of
small
improvements,
because
the
dependency
on
the
big
issue,
shipping
and
challenges
getting
planned.
Therefore,
everything
slow
down
and
the
subsequent
or
even
alternative
small
solutions
have
to
be
planned
around
this
another
one
is
the
law
of
triviality,
also
known
as
the
bike
shed
effect,
and
this
highlights
the
phenomenon
of
trivial
issues
receiving
disproportionate
attention
versus
big,
complex
ones.
It's
an
interesting
one.
A
I
would
check
it
out
what
if
boring,
Solutions
fall
under
the
spell.
If
brakes
are
our
strategic
approach
of
small
iterative
solutions,
that's
value
stream
that
keeps
going
and,
of
course,
the
last
one
or
one
that
I
thought
of
is
the
ever
elusive
search
for
perfection.
If
anyone
saw
the
amazing
presentation
by
Taylor
about
impostor
syndrome
over
at
Virtua,
contribute
they'll
know
like
he
spoke
to
all
the
vampires
that
fall
under
that
category.
They
are
all
blockers
for
small
solutions
all
right.
A
Well,
let's
take
a
look
at
some
of
these
that
we've
been
working
on
in
a
secure
and
defend
team,
and
if
we
see
you
out
there
yawning
and
looking
at
slack
or
if
you
just
want
to
take
a
nap,
you
know
what
I
won't
be
offended
actually
to
the
contrary,
we'll
be
complimented
by
it
all
right.
So,
let's
start
with
the
dependency
list.
A
The
problem
here
is
the
list
of
components
shown
in
this
particular
UI
may
not
be
up-to-date,
as
it
might
not
reflect
the
head
of
the
default
branch,
the
latest
job,
so
users
should
be
aware
that
they
might
be
looking
at
old
data
here,
possibly
outdated
versions
of
the
project's
components
and
nowhere
in
the
screen.
Is
it
even
explicit
when
or
where
the
data
is
coming
from
we're
just
looking
at
a
bunch
of
components,
the
small
iteration
that
we
did
here
is
we
linked
at
the
documentation
just
to
help
developers
across
the
project?
A
Understand
what
they're,
seeing
here
we
added
subtext
that
frames
the
page
findings
based
on
latest
and
there's
a
new
update,
the
small
solution
to
that.
That's
not
here
that
says,
latest
successful
pipeline,
which
is
just
a
better
copywriting
there
and
it
links
to
the
pipeline
page,
so
they
can
go
directly
to
it
and
when
it
was
last
updated
two
days
ago
now.
The
next
step
here,
though,
is
we
need
to
explicitly
warned
when
a
dependency
scan
job
failed.
A
So
that's
also
something
that
Rebecca
and
our
team's
taking
a
look
at
doing
on
the
security
dashboard
just
being
explicit
about
when
the
job
failed,
because
the
dashboard
is
in
the
same
boat
as
this
and
if
there's
a
job
failure,
the
data
that
we
may
be
looking
at
may
be
out
of
date,
sticking
with
the
dependency
list.
The
top
priority
that
we
have
for
this
page
as
it
relates
to
our
features,
is
this
job
to
be
done
here
and
basically,
what
that
is.
Is
they
we
want
to
display
vulnerabilities
that
relate
to
our
dependencies.
A
A
Okay,
so
what
are
the
small
iterations
that
we
did
to
clean
some
of
the
sudden?
The
first
one
is
we
remove
the
vulnerability
tab,
which
was
hiding
vulnerabilities
in
time.
We
have
a
sort
order
here
which
we
defaulted
to
severity,
which
already
existed.
We
just
defaulted
to
it
and
that
brought
the
severe
the
the
vulnerabilities
and
it
displayed
them
in
space
and
it
made
them
prominent.
A
That's
the
first
thing
you
see
on
the
page:
we
removed
the
safe
status
and
therefore
we're
only
calling
attention
to
the
actual
dependence
that
have
vulnerabilities
and
we
applied
this
risk
label.
This
is
also
a
risk
label
that
we
applied
to
the
license
list
as
well
for
out
of
policy
licenses
and
then
just
a
small
fix
here
is
we
brought
the
component
name
and
the
version
column
together.
A
What
are
some
next
steps
that
we
want
to
do
with
dependency
list?
Well
right
now
we're
looking
at
an
expanded
view
which
does
show
vulnerabilities
to
related
component.
However
they're
not
linkable,
yet
now
this
is
dependent
on
the
upcoming
objects
page,
which
is
a
dedicated
page
to
vulnerabilities.
So
users
can
have
discussions
around
vulnerabilities
similar
to
an
issues
page,
but
it's
not
don't.
A
There's
a
distinction
there:
you
can
apply
statuses
to
the
objects
page,
you
can
create
issues
around
it,
but
that
is
dependent
on
the
completion
of
that
then
we'll
be
able
to
link
these
so
they'll
be
one
step
forward.
The
second
thing
we
want
to
do
in
dependency
list
that
we're
looking
at
is
we
want
to
help
users
understand
where
and
how
these
dependencies
affect
the
project
now
we're
just
kind
of
given
them
a
list.
A
Hey
here
are
some
ones
that
are
scanning
have
says
that
there's
vulnerabilities,
but
it's
not
as
simple
as
just
you
can't
just
go
in
there
and
remove
a
dependency.
You
need
help
the
user
understand
where
these
dependencies
live
amongst
each
other
and
how
it's
affecting
their
project.
And
then
the
third
is
better
unifying
the
license
list
with
license.
Compile.
Excuse
me
better,
you
know,
find
a
dependency
list
with
license.
Compliance.
Two
separate
features
two
separate
scanners,
but
there
shouldn't
be
two
separate
user
interfaces
for
that
we
can
merge
them
together.
A
A
A
This
would
require
this
would
result
in
multiple
objects,
the
same
type,
different
images,
and
this
is
kind
of
confusing,
so
the
first
iteration
we
had
here
is
existing
the
existing
work,
leveraging
the
existing
filtering
pattern
that
we
have
there
and
the
user
can
now
select
the
specific
image,
not
perfect,
but
they
can
dig
down
and
start
dealing
with
those
vulnerabilities
individually
per
image.
Now.
The
next
steps
we
want
to
do
here,
though,
is
simplifying
remediation
across
different
images
and
there's
a
lot
of
UX
actually
parallels
to
what
we're
looking
at
with
our
scanner.
A
Scanner
integrations
as
well,
but
something
Camellia
has
been
looking
at
and
in
fact
you
may
recall
one
of
the
previous
showcases
where
it
was
grouping.
This
was
along
the
same
lines
and
that
will
help
the
immediate
the
remediation
process
for
these
multiple
same
vulnerabilities,
so
again
same
vulnerabilities,
different
images.
There
could
be
a
better
way
to
address
all
of
them
together,
instead
of
one
by
one
by
one
and
also
recently,
we've
been
working
with
the
package
team
to
bake
security
into
the
container
registry.
A
So
thank
you
in
for
hosting
such
a
great
big
session,
and
what
we
want
to
do
there
is
with
these
different
images
is
when
there's
Wellner
abilities.
We
want
to
bring
that
into
the
workflow
that
you
see
in
the
packard
packaged
registry
UI
or
even
more
fundamental,
what
if
containers,
aren't
even
being
scanned.
So
that's
something
where
we
have
some
designs
out
there
for
and
that's
actually.
The
first
step
is
making
sure
that
they're
configured
correctly,
okay
sticking
with
the
security
dashboard.
This
is
our
upcoming
suggested
solution
feature.
A
This
is
really
exciting
because
for
container
scanning
and
dependency
scanning
we
do
have
a
database
or
are
times
where
versions
need
to
be
updated
or
vulnerabilities,
have
known
patches
and
we'll
be
creating
merge
requests
automatically
for
users
to
then
review
and
to
just
merge.
So
this
takes
this
one
step
out
of
the
process
where
they
actually
have
to
manually
do
this
now.
The
problem
to
solve
here
is
as
we
roll
this
feature
out.
A
We
are
leveraging
a
notification
banner
here
and
it's
gonna
be
like
I
said
in
the
security
dashboard,
and
the
upside
here
is
that
it
promotes
learnability
and
it's
visible,
but
it
has
low
noise
and
then
the
flow
here
is
when
they
do
view
security
fixes
they'll,
go
to
the
merge
request
list
with
a
pre
filtered
label
of
the
feet
which
is
assigned
to
all
these
auto
created,
merge
request
the
gitlab
suggested
solution
label.
So
there's
a
great
learn
ability
aspect
to
that.
A
The
next
steps
we
want
to
do
here
is
how
we're
surfacing
messaging
in
general.
We
don't
want
to
rely
on
banners.
We
have
other
messages
that
we
want
to
show.
We
don't
want
to
have
like
a
banner
frenzy
here,
and
the
team
is
auditing.
All
these
different
messages
again,
another
one
is
like
pipelines
failing
and
so
on,
there's
a
number
of
different
messages,
and
we
want
to
better
sort
of
have
a
more
centralized
message
for
this
okay
jumping
to
license
compliance.
This
feature
is
where
this
is
related
to
our
license.
A
Scan
and
users
can
add
policies
to
deny
certain
licenses
that
are
out
of
compliance
with
with
their
organization
we're
looking
at
a
merged,
/
quests
and
as
a
maintainer
view
when
we're
looking.
At
this
view,
we
see
in
the
merge
request
widget
that
two
licenses
were
detected
and
then
I'm
taking
a
look
at
this
and
I.
Don't
really
know
what
this
means,
this
X
icon
and
this
circle
icon
when
in
reality,
the
X
icon
means
that
it's
denied
it's
out
of
compliance.
The
circle
icon
means
that
it
has
no
classification.
A
The
user
would
actually
have
to
click
this
to
look
at
the
modal,
so
the
UI
is
not
explicit
about
the
problem,
nor
about
the
suggested
resolution
and
then,
even
though
an
out
of
compliance
license
has
been
detected,
the
merchant
requests
may
be
merged.
That's
something
else.
We're
taking
care
of
in
the
next
milestone
as
well
deny
will
mean
deny
and
it'll
stop
disallow,
merge
requests.
We
still
have
the
approval
rules
that
can
override
those
denials,
but,
as
you
can
see
as
a
maintainer,
they
can
still
merge
this,
even
though
a
denied
license
has
been
committed.
A
So,
what's
the
small
iteration
that
we
did
here?
Well,
we
put
text
in
the
widget
section
here
to
specify
that
a
policy
violation
is
is
in
there
and
then
we
brought
out
the
categories
with
the
header
here
denied
and
then
said
explicitly
what
this
means:
it's
out
of
compliance
with
the
project's
policies
and
should
be
removed,
so
that
about
the
developer
knows
with
that,
what
to
do
next
and
why
the
merge
request
cannot
be
merged.
A
Some
vulnerabilities
detected
here,
we're
looking
at
that
X
icon
again,
and
we
have
no
idea
what
that
means,
and
so
and
and
when
it's
fixed,
there's
a
check
icon.
So
this
isn't
it's
unclear
what
that
means.
It's
unclear
what
what
we're
looking
at
and
the
other
thing
is-
is
we're
already
using
those
icons
for
license
compliance
so
and
they
have
different
meanings
than
what
we're
communicating
here.
The
meaning
is
explicit
here
that
these
are
newly
detected
in
this
merge
request.