►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
I
added
one
topic
from
previous
discussions
so
based
on
our
past
discussions
and
that
we
had
agreed
that
the
mr
security
reports
had
graduated
from
planning
breakdown.
I
took
andy's
suggestions
of
the
four
different
steps
that
he
thought
made
sense
as
far
as
our
mvc
epics
goes,
so
you
can
see
that
I
created
four
epics
under
that
mr
security
report
mvc,
based
on
those
suggestions.
Thank
you
for
that
andy.
Those
are
great.
The
goal
now
is
to
assign.
A
Well,
I
can't
assign
epics
to
people,
and
this
is
one
of
the
main
reasons
I
put
this
on.
The
agenda
is
to
identify
dris
one
person
from
the
front
end
and
one
person
from
the
back
end
for
each
epic
and
have
you
guys
create
those
implementation
issues
you
could
just
do
you
know
the
basic
skeleton
of
them
and
then
we
will
assign
them
off
for
refinement
like
our
normal
process.
A
So
the
best
way
I
can
think
of
doing
that
is
to
just
at
mention
people
in
the
epic.
I
know
that
can
create
problems
of
visibility
if
you're
really
just
looking
at,
what's
assigned
you
on
a
board,
because
again
I
can't
assign
an
epic
to
somebody.
I
could
create
an
issue
under
each
epic
that
says,
create
the
issues
and
then
assign
that
to
somebody.
A
Okay,
so
today
I
will
be
taking
this.
You
know
since
there's
four
back-end
engineers
I'll
probably
give
one
to
each
of
the
back-end
engineers
and
then,
as
far
as
the
front-end
goes,
one
person
will
get
two
and
then
work
with
your
counterparts
on
the
the
team
front
and
back
end
to
make
sure
that
it's
covered
and
then
we'll
we'll
work
from
there
because,
like
I
said
it's
going
to
go
into
refinement,
it'll
follow
our
normal
process.
A
I
I
don't
know
if
I'm
expecting,
if
you
guys
want
to
assign
them
off
to
individuals
for
refinement.
That's
fine!
If
you
want
to
pick
it
up
yourself
for
refinement,
that's
fine
as
well!
I
think
it's
always
good
to
have
another
pair
of
eyes
on
things.
So
so
you
know
if
you're
the
person,
that's
identifying
those
if
you
want
to
refine
them,
fine
have
someone
else
on
your
team.
Take
a
look
at
the
issues
you've
created
to
make
sure
it
makes
sense
to
them
too
so
cool
and
thanks
again
andy.
A
I
really
think
that
was
a
great
approach
from
the
the
ux
of
you
know.
Here
are
some
like
logical
buckets
of
how
this
could
break
down
and
benefit
our
customer
and
iterative
steps
for
sure
all
right,
demos,
savage.
You
got
a
couple
here.
Thank
you
anything
you
want
to
highlight
or
verbalize
around
them.
C
It's
still
working
progress
regarding
the
activity
column
decided
to
iterate
on
this
I'll,
probably
create
four
or
five
five
mars,
for
this
first
step
was
to
move
the
remediated
patch.
The
second
step
is
to
move
the
issues
link.
Then
I
will
add
the
the
filter
and
then,
if
one
more
mi,
if
there
is
any
cleanup
or
whatever
so
yeah,
that's
it.
D
Josh,
do
you
know
if
we're
using
the
gitlab
badge
component
for
those.
C
So
we
had
the
rema
remediated
batch
component.
I
modified
it.
I
think
we're
not
using
that
component
that
you're
referring
to.
I
was
not
aware
of
that.
Maybe
I
could
I
can
switch
them.
D
Yeah
those
are
brand
new,
as
of
like
one
or
two
milestones
ago:
they're,
just
a
slight
color
variation.
C
Yeah
I
that
was
a
bit.
I
tried
to
pick
the
right
color,
but
okay,
I'm
I'm
gonna
check
the
the
component
and
then
create
nmr
for
replacing
them
for
sure.
C
Share,
oh
sorry,
go
ahead
since
we're
think
got
a
question
for
for
andy
the
horizon,
so
we
have
the
created
issue
next
to
the
vulnerability
title,
so
the
one
that
we
used
to
have-
and
we
still
have,
shall
I
remove
that
as
well.
A
Was
that
did
I
get
that
right?
The
created
icon
is
this
around
the
issue
created
display,
savage
sorry,
sorry,
I
was
trying.
A
Your
question
in
the
agenda
just
for
reference
I
and
I
kind
of
missed
what
you
said.
C
There
is
an
issue
next
to
the
vulnerability
title,
the
the
one
that
it's
already
created.
E
C
We
used
to
link
that
question
was
whether
we
should
move
that
into
the
new.
So
we
should
just
remove
that
because
we'll
now
display
all
the
issues.
B
My
favorite
issue-
I
I
put
this
into
demo
or
to
show
it
off
here,
because
I've
been
working
very
closely
with
savash
on
this,
and
I
think
it's
in
a
pretty
stable
point
at
at
this
point.
It's
up
for
review
again
and
I'm
writing
tests,
and
so
I
think
we
savage
has
helped
me
get
a
good
direction
down
with
the
code.
Andy
if
you
could
take
a
look
at
it
as
a
ux
review,
that'd
be
great
but
yeah
exciting.
This
is
gang
into
a
stable
state,
so.
C
That's
it.
That's
the
mark
that
you
asked
me
to
rewrite
alexander
yeah.
Perhaps
since
we
worked
on
this
together,
maybe
daniel
can
take
a
look
at
it
so
that
it's
a
like
third
pair
of
eyes.
Maybe
he
will
have
or
yeah
just
what's
the
suggestion.
B
Yeah,
definitely
I
don't
know
what
daniel's
bandwidth
is
right
now,
but
I'll
ask
him.
A
And
that's
a
great
reminder:
samasha
is
going
to
be
out
next
week,
so
if
anyone
needs
him
talk
to
him
now.
A
No,
this
is
great
information,
so
thank
you
around,
given
us
some
insights
into
how
to
get
more
information
around
the
ux
research
process.
I
know
you
guys
work
really
hard
on
making
sure
that
the
requests
that
you
bring
to
us
have
been
thoroughly
researched.
F
F
It
is
hot
garbage
because
it
puts
text
below
all
the
videos
automatically.
It
makes
no
sense.
So
if
you
want
to
laugh,
that's
good,
but
so
dovetails
the
system
that
the
ux
research
team
adopted,
I
guess
several
months
ago,
and
the
idea
is
that
it
really
allows
kind
of
collating
all
the
information
from
these
studies.
And
then
you
can
pick
out
snippets
of
the
video
things
that
people
said
and
tag
them
and
sort
of
group
them
up
into
insights.
So
it's
really
really
helpful.
There's
a
lot
of
information
there
because
of
the
licensing.
F
It
is
expensive,
but
we
can
get
read
only
access,
so
we
just
need
your
email
address.
So
that's
why
you
need
to
ping
us
and
we
can
add
you
to
it
and
we've
got
the
next
session.
I
think
we're
targeting
the
29th.
So
if
you
want
to
sit
in
live
we'll,
do
it's
usually
myself,
andy
and
tali,
depending
on
scheduling,
we
feel
comfortable
with
one
additional
person
per
interview.
F
A
G
With
so
essentially
at
some
point
we
were
investigating.
If
there
is
anything
we
could
do
to
improve
the
computing
state
of
a
finding
and
the
last
time
I
did
check
if
there
are
like
any
low
hanging
fruits.
G
Unfortunately,
the
answer
was
no,
so
we
need
to
take
a
long
and
hard
look
at.
What's
the
current
algorithm
for
doing
that,
if
there
is
anything
we
can
do
to
speed
it
up
and
yeah,
I
was
initially
proposed
to
use
advanced
database
features
which
we
were
in
the
middle
of
implementing,
so
the
database
team's
answer
was
like
well,
we
are
not
sure
if
you
can
do
procedures
and
triggers
to
the
database
now.
A
A
You
know
be
focused
on
by
one
person
and
and
get
an
implementation
plan
and
know
which
direction
we're
going
to
go.
If
that's
the
same
way,
you've
already
started
great.
If
we're
going
to
adjust,
then
looking
at
our
questions
for
plenty
breakdown,
this
is
an
engineering
driven
issue.
A
G
E
On
so
the
thing
is
like
recently,
I
started
working
on
improving
the
performance
of
mr
security
tab
by
just
saving
the
vulnerabilities.
I
mean
the
findings
for
all
the
pipelines
into
the
database.
E
E
So
if
we
actually
merge
it,
then
it
will
be
quite
easy
to
calculate
the
state
of
the
finding
if
it's
dismissed
or
not
without
having
the
need
of
downloading
all
the
artifacts
from
the
repository
into
the
memory.
So
we
can
actually
calculate
this
state
in
the
database
layer.
E
Actually,
probably
we
will.
We
will
need
to
introduce
more
logic
to
just
check
if
there
is
a
feedback
in
the
database
for
the
data
for
this
finding
by
just
joining
to
the
feedback
table.
E
A
All
right,
this
one
has
been
open
for
a
little
while,
so
I
know,
there's
some
discussion
in
there.
G
The
only
thing
that
remains
unclear
to
me
now
is
whether
this
is
actually
a
problem,
because
when
I
first
discussed
it
with
wayne
and
thomas,
we
were
unsure
if
this
impacts
us
really
badly.
If
we'd
like
to
prioritize
this,
because
this
impacts
us
very
badly-
and
we
have
some
performance
problems
with
regards
to
this
functionality
and
to
be
honest,
I
am
still
not
sure
if
this
is
a
major
performance
problem.
If
we
need
to
prioritize
that.
E
Actually,
I
was
also
preparing
a
dashboard
on
on
kibana
to
actually
check
the
performance
of
this
security
tab
and
it's
miserable
like
most
of
the
time
timeouts,
and
this
is
actually
why
I
have
been
working
on
this
for
a
long
time-
it's
it
was
taking
more
than
a
month.
Actually.
So,
with
that
with
the
changes
I
introduced,
probably,
we
will
improve
the
performance
a
lot,
but
I
think
we
need
to
address
this
if
my
changes
will
not
fix
the
problem.
G
A
A
Okay,
so,
based
on
that,
it
does
feel
like
we
can
move
this
out
of
planning
breakdown.
So
going
back
to
our
questions,
you
know
the
requirements
are
are
clear
and
that
we
know
we
have
performance
problems
and
we've
been
looking
into
these
and
you
know,
based
on
the
conversation,
we
had
we're
going
to
leave
this
open
dependencies.
You
know
going
through
the
questions
additional
dependencies
outside
of
our
team.
A
Are
there
any
that
we
need
to
call
out
as
part
of
this,
I
know
you've
been
working,
probably
with
a
database
team,
no
okay,
and
then
this
doesn't
research
solution.
Validation
doesn't
really
apply
here.
Here's
a
good
question:
is
this
small
enough
to
complete
in
one
iteration
and
or
should
we
break
this
down
at
all
into
any
additional
issues?.
E
Actually
after
I
merge
my,
mrs
probably
we
can
finish
this
in
just
one
iteration
yeah,
just
perfect
fingers.
A
Okay,
so
it's
this
is
like
this
is
met
all
of
our
plenty
breakdown
criteria.
After
this
call,
I
will
move
it
into
refinement
name
it
I'm
going
to
assign
this
to
you,
because
it
is
dependent
on
the
outcome
of
this
other
work
that
you're
describing
does
that
sound?
A
Okay,
okay,
excellent-
and
we
have
this
sub
question
that
I'm
trying
to
ask
now
whenever
we
move
something
out
of
planning
breakdown
or
refinement
is
around
end
to
end
tests,
and
I
don't
think
that
applies
for
database
performance
improvements,
I'm
just
calling
it
out
for
the
group
so
that
you're
aware
that
we
did
add
another
question
here
to
our
our
planning
breakdown
survey.
So
we
can
at
mention
our
stable
counterpart
will
meeks
early
on
to.
Let
him
know
that
you
know
there'll,
be
some
end-to-end
testing
work
coming
up
all
right.
A
D
B
B
Meeting
you
zoom
lets:
you
hit
the
record
button,
but
if
you
don't
actually
have
permissions,
it
says:
oh,
you
actually
can't
do
that,
but
does
it
after
the
fact.
Similarly,
right
now,
you
can
filter
in
the
dashboards
by
a
filter
that
will
not
produce
any
results
and
there's
an
empty
state
says:
hey
you're,
filtered
in
producing
results,
and
this
can
be
annoying,
and
so
there
is.
This
ticket
is
to
implement
the
ability
to
disable
filters.
B
If
we
know
they're
not
going
to
produce
any
results
up
front,
so
it
won't
update
dynamically
based
on,
like
you
know,
say
there
are
say
you
filter
by
a
severity
of
high
and
then
it's
not
going
to
disable
a
scanner.
If
there's
no
scanners,
that
produce
results,
so
a
user
can
still
get
to
that
empty
state.
But
if
there's
no
severity
of
critical
vulnerabilities
at
all,
then
that
would
be
disabled
and
so
again
with
the
scanner
filter.
B
We
get
this
information
up
front
now
and
my
mr
disables
scanners
that
don't
produce
anything
if
there's
no
das,
no
sas
or
whatever,
but
we
need
to
similarly
do
that
for
the
other
filters,
so
that
is
by
project
by
state
and
then
by
severity.
B
C
When
do
we
fetch
that
information
from
so
if
under?
If
I
understand
correctly,
we
want
to
know
upfront
whether
filters
produce
results
or
not
so
we're
going
to
do
this
when
the
user
clicks
on,
for
instance,
the
scanner
filter,
and
then
we
do
a
call
to
the
backend
to
see
if
there
are
results
and
then
gray
out
the
ones
that
are
not
producing
any
results
or
is,
is
that's
that's
the
issue
right.
I
understood
it
correctly.
B
Yeah,
and
for
that
is
correct,
but
for
the
scanner
filter
work
it.
This
is
a
graphql
call
that
happens
immediately
when
the
scanner
filter
is
rendered
and
instantiated,
and
so
it
happens.
It
saves
that
data
and
then
we're
able
to
make
decisions
off
of
that.
So
it
will
not
be.
It
will
not
be
on
every
click
of
the
filter.
At
least
it
shouldn't
be.
A
B
That
is
a
great
question.
It
can
right.
I
I
didn't
have
to
think
about
that
for
the
scanner
filter,
because
you
can't
switch
a
desk
vulnerability
to
a
sas
one,
but
that
will
be
something
we
need
to
think
about,
and
it's
something
I
did
not
think
about.
So
thank
you.
A
G
My
question
is
that
if
we
do
filter
by
a
project,
then
the
remaining
filters
might
change
as
well.
So
I'm
looking
at
the
first
screenshot.
So
if
you
have
like
the
project
filter,
if
you
filter
a
project,
then
the
availability
of
status
filters
might
change
as
well.
B
Right
and
that's
a
great
question,
and
I
think
that
when
you
load
the
page
initially
where
these
these
filters
should,
the
call
should
take
into
account
not
take
into
account
any
filters
that
users
filter
by
it
should
just
be
like
all
the
vulnerabilities
for
all
the
projects.
B
Is
there
a
high?
Is
there
a
low?
Is
there
detected
whatever?
And
if
you
filter
by
project
it
shouldn't,
I
think
it
would.
I
mean
I
think
it's
out
of
scope
to
have
them
dynamically
update
the
other
filters
by
selecting
one
filter,
and
I
think
a
user
is
fine.
If
a
user
still
gets
to
an
empty
state
in
this
iteration,
maybe
in
a
future
one
but
okay,
that
seems
all
more
complicated
than
a
than
like
a
first
step.
B
I
think
it's
out
of
scope
personally,
maybe
other
people.
E
Have
feelings
about
that?
So
I
have
a
question.
So
the
thing
is
like
first
of
all
like
this
is
a
really
nice
addition
from
the
point
like
front
point
of
end
user.
It's
definitely
definitely
improves
the
user
experience,
but
the
thing
is
like
it
feels
like
it's
a
bit
complex
to
be
a
first
step.
What
about
like,
starting
just
only
by
with
one
filter
like
maybe
just
the
status
filter?
Does
it
create
confusion
rather
than
fixing
a
problem
for
the
end
user?
E
B
Yeah
another
great
question
I
so
it's
already
being
implemented
on
the
scanner
filter
initially,
and
I
think
the
you
ask
a
great
question
like
is
this
going
to
be
confusing
that
some
of
them
are
disabled,
having
options
disabled
with
others
or
not,
and
I
think
for
the
scanner
filter.
It
makes
sense
because
we
already
show
the
user
a
top
like
a
top
notification
that
says
hey.
These
scanners
are
not
enabled,
and
so,
if
they're
not
enabled,
then
they're
not
going
to
show
any
vulnerabilities,
and
so
it
makes
sense
to
also
disable
them.
B
Whether
this
adds
more
confusion.
If
we
just
do
the
status
or
just
do
severity,
I
could
see
that
and
I
don't
I'm
not
a
uxs
expert.
Do
we
have
any
anyone
who
works
with
the
product
in
depth
or
maybe
what
user
experience
in
depth
here?
That
could
talk
about
that.
It.
D
Sounds
like
it
sounds
like
the
behavior
extending
to
all
the
filters,
except
for
the
dynamically
generated
ones,
is
a
safe
place
to
go
with
this.
I
don't
think
there
will
be
too
much
confusion.
D
There
probably
will
be
some
clicking
around
and
some
questions
of
like.
Why
are
these
disabled,
but
then,
if
I
click
into
like
see,
dismissed
and
I
see
none,
that
would
probably
be
more
confusing
than
any
expectation
of
seeing
one
or
many
of
those.
D
E
Maybe
there's
a
way
to
like
emphasize
that,
like
some
of
the
filters
are
dynamic,
maybe
I
don't
know,
maybe
just
changing
the
font
color
or
making
it
bold
or
like
putting
a.
I
don't
know
like
icon
or
something.
B
A
That
tells
you
that
it
could
be
turned
off.
I
think
it
was
what
was
being
proposed
right
so
you're
indicating
that
it's
disabled,
but
if
you
know,
if
certain
filters
are
going
to
be
dynamic
and
certain
aren't,
I
think
the
suggestion
on
the
table
is
that
you
somehow
display
in
the
ux
that
this
this
it's
on,
but
it
could
be
disabled
based
on
what's
resulting
from
your
data.
E
Because
the
thing
is
like,
for
example,
if
you
are
not
applying,
if
you
are
not
going
to
apply
this
for
the
severity
filter,
for
example,
if
I
see
everything
is
enabled,
but
once
I
click
one
of
them,
if
I
see
no
results,
probably
I
will
open
a
bug
issue
saying
hey.
This
filter
is
broken
because
I
will
know
that,
like
some
of
the
like,
some
of
the
filters
are
applying
this
convention.
So
if
there
is
no
result,
they
are
disabled.
This
must
be
disabled
as
well.
D
D
So
if
we're
generating
these
on
page
load,
then
that
could
be
a
solution.
I
think
a
little
more
investigation
on
the
mechanics
behind
this
could
help.
I
would
hate
to
just
kind
of
like
have
a
like
a
call
out
like
raising
its
hands
like
hey.
This
is
a
dynamic
filter,
because
we
don't
really
do
that
anywhere
else,
but
there
could
be
a
way
to
communicate
that
if
we
can't
get
the
mechanism
to
work
in
our
favor.
F
I
guess
one
thing
not
not
to
say
we
shouldn't
go
forward,
because
I
really
do
like
this
we're
going
to
add
more
filters
in
the
near
future
for
this,
so
keeping
in
mind
the
complexity
of
having
to
track
that.
As
you
know,
if
we
get
four
or
five
things
at
the
top,
as
you
change
those
filters
you're
going
to
have
to
change
everything
dynamically,
I
just
want
to
make
sure
we're
not
doing
a
was
it
a
premature.
F
A
So
we're
at
the
end
of
our
time,
matt
I'm
going
to
let
you
decide
where
to
put
this
from
a
milestone
perspective.
I
put
it
in
13
6
after
it
was
created,
but
that's
just
temporary.
So
if
you
don't
mind
updating
that
based
on
this
discussion,
it
does
sound
like
we
need
more
discussion,
or
do
you
guys,
I
mean
to
say
that
it's
even
through
planning
breakdown.
A
See
thumbs
up,
let's
see
some
nods,
okay,
we'll
leave
this
on
the
agenda
and
prioritize
it
based
on
where
it
falls
in
future
iterations.
Again,
it's
a
it's
a
great
suggestion
for
improvement
and
I
encourage
everyone
to
think
the
way
alexander
is
you
know
when
you
see
ways
that
we
can
improve
our
customer
experience,
create
issues
for
them
and
bring
them
to
the
table,
and
on
that
note
we're
done.
I
hope
everyone
has
a
fantastic
tuesday,
bye.