►
From YouTube: Defend: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Defend:Threat Insights group
C
A
B
Just
want
to
so
there's
been
some
advancements
in
the
graph
QL
pagination
issue
that
was
reported
way
back
when
Sam
tried
to
add
pagination
to
the
security
dashboard.
It
apparently
has
been
fixed
the
ticket
to
investigate
pagination
on
the
security
dashboard
with
graph
QL
has
been
updated,
perma
met
and
sloshed.
Thank
you
and
there's
still
some
performance
concerns,
but
this
is
something
this
is
a
good
step
forward.
A
Yeah,
like
you
said,
we
have
a
spike
for
that
the
technical
spike
in
13.2,
so
that
information
will
feed
that
investigation
and
then
we'll
decide
what
we're
gonna
do
with
that.
Hopefully
shortly
thereafter,
so
my
item
keeps
coming
up.
I
figured.
We
should
talk
about
it
here.
We
have
this
notification
when
a
vulnerability
is
resolved,
the
notification
happens
in
two
places
on
the
standalone
page
and
then
also
on
the
dashboard,
and
we
have
a
sneaking
suspicion
that
the
dashboard
notification
is
not
working.
It
was
implemented,
it
was
tested.
A
It
doesn't
that
we
can't
see
it
when
we'd
expect
to
see
it
now.
So
there's
just
been
a
lot
of
conversations
and
issues
and
I
figured
you
know
per
handbook
once
we
have
so
you
know
a
few
back
and
forth,
so
we
should
bring
it
to
a
sink
in
this
discussion
and
fortunately
I,
don't
I
didn't
ask
anyone
to
look
into
this
advance.
Does
anyone
have
any
background
on
this
that
they
want
to
share
I,
think
it
was
Sam
Beckham
that
originally
implemented
this
in
the
front
end?
Has
anyone
looked
at
this
at
all?
D
A
B
A
So
it's
a
good
call-out
better,
so
the
customers
do
still
have
this
information,
but
they
have
to
click
all
the
way
through
to
the
vulnerability,
deep
detail.
Page
just
see
it
as
far
as
we
know,
that's
still,
working
correctly,
we
should
probably
put
a
little
bit
of
effort
into
testing
the
confirm
that,
but
given
that
the
santalune
page
isn't
using
graph
QL
and
the
dashboards
are
I'm
not
sure
how
much
reusability
there
is
there
between
those
two
areas
or
implementations,
this
isn't
13.2.
A
So
we
can
also
kind
of
look
at
this
as
a
planning
breakdown
and
again.
The
main
reason
I
wanted
to
bring
this
to
everyone's
attention
was
just
to
make
sure
that
everyone
was
aware
that
this
was
working
at
a
certain
point.
It
was
verified,
I,
believe
even
in
production
based
on
the
comments
on
the
issue,
so
we're
really
kind
of
recategorize
in
this
issue
as
a
bug
now,
because
it's
popped.
C
D
E
F
Maybe
I'm
totally
missing
the
point,
but
would
it
not
make
more
sense
to
just
automatically
update
the
status
of
a
vulnerability
when
Windows
scan
against
master
occurs
and
we
realize
that
something
is
missing.
Just
update
that
or
do
we
not
have
that
because
the
ability
to
see
up
the
chain
like
that
I.
E
F
E
F
A
We
stopped
we
would
need
to
make
updates
to
be
consistent
in
the
standalone
page
as
well.
I
mean
the
messaging
that
we
have
to
the
customer
and
the
standalone
page
says
verify.
The
vulnerability
has
been
remediated
before
changing
its
status,
so
this
is
very
much
an
intentional
customer
workflow
move
here.
So
if
you
want
us
to
hold
off
on
fixing
the
remediation
badge
on
the
dashboard,
because
you
want
to
take
this
a
different
directions
that
would
be
different,
I
don't
want
to
repurpose
this
bug
that
popped
up
from
a
feature.
That's
not
working
anymore.
F
A
To
know
that
you
guys
are
gonna,
be
discussing
this
and
then
there
might
be
a
change
in
this
behavior
in
the
future,
but
for
right
now
we're
going
back
to
what
the
original
goal
was
of
displaying
this
badge
as
an
informational
badge,
but
not
actually
updating
the
status
of
the
vulnerability
sweet
alright.
So
this
is
a
signed
right
now
to
Jonathan
and
Vash
for
I.
A
Think,
do
you
guys?
Are
you
comfortable
saying
that
we're
kind
of
in
a
refinement
with
this
bug,
I,
don't
think
we
really
need
planning
breakdown
unless,
if
you
guys
feel
like
the
issue
itself
needs
to
be
samosas
mic
is
not
working,
we
can
read,
you
have
something
to
say:
I
can
read
it
in
your
voice.
If
you
would
like.
D
D
There's
a
similar
there's,
a
related
issue,
I
believe
I
believe
it'd
be
related,
the
one
that
delete
brought
up
where
the
if
the
branch
goes
away,
being
able
to
track
it
in
the
new
branch
or
the
master
branch
and
being
able
to
connect
those
and
so
getting
that
part
working
would
probably
allow
us
to
be
able
to
track
if
it
had
been
remediated
or
not.
Otherwise,
you
know
it
you
never
having
to
track
like
line
numbers,
and
even
those
can
get
off
from
branch
to
branch.
D
F
F
But
then
the
Gandy
that's
a
fair
point
that
if
a
human
wants
to
go
and
verify
that
something
was
actually
not
just
removed
but
fixed
properly,
because
if
I'm,
if
I'm
lazy,
I
might
just
change,
you
know
the
name
of
something
and
it's
not
there
anymore,
but
I.
Actually,
you
know
left
the
ball
or
building
anyway,
yeah
I
think
that's
part
of
a
bigger
conversation.
G
Ready
so
I
first
said
that
I
didn't
check
this.
There's
you
but
I
actually
even
commented
there.
So
I
I
did
I
just
forgot,
so
I
think
the
issue
is
because,
while
moving
to
graph
keel,
we've
we
didn't
so
the
back
end
doesn't
provide
a
flag.
So
the
front
end
misses
this
information.
It's
even
the
comment.
I
think
I
confirm
that
with
Ellen,
so
there
should
be
some
back
and
work
here
first
and
then,
if
it's,
if
it's
not
implemented,
then
we
can
work
on
the
front
end
part.
A
F
A
A
Cool,
thank
you,
I'll,
be
looking
at
those
later.
I
hope
everybody
else
does
as
well
and
we
are
on
planning
breakdown,
Matt
I'll.
Let
you
talk.
F
F
So
I
guess
the
the
first
thing
to
point
out
is
we're
still
in
design
on
this
one.
So
this
is
more
so
everybody
can
be
aware
of
this
issue
and
start
thinking
about
it.
Early
I
know,
that's
been
kind
of
a
we'll
say.
Universal
request
is
to
get
things
that
we're
working
on
in
front
of
engineering
and
get
your
feedback
on
what
looks
like
we're
going
down
a
path
of
extreme
technical
difficulty
or
impossibility
early,
but
this
is
going
to
be
one
of
the
areas
of
focus
that
we're
going
to
be
looking
at.
F
Probably
this
is
going
to
be
the
next
immediate,
large
chunk
of
work,
so
the
MRR
security
report
or
the
Ember
security
widget
or
whatever
we
decide
to
probably
needs
a
better
name.
Is
there
we
go
Lindsey?
Has
it
pulled
up
right
there?
It's
that
little
thing
right
in
the
middle
that
shows
the
scans
in
the
M
R
itself.
So
there
is
a
company-wide
initiative
to
actually
redo
a
lot
of
this
information
in
general.
Just
because
looking
at
it
it's
it's
hard
to
read.
There's
a
lot
going
on
here.
F
There
are
inconsistencies
between
the
different
little
components
and
widgets,
and
we
want
to
try
to
simplify
this
down
so
that
users
aren't
really
getting
information
blindness
which
is
happening
today.
Either
people
are
not
clicking
on
expand
because
they
don't
know,
that's
the
thing
that
they
can
do
for
the
security
information
or
they
do
and
right
now
at
list
every
single
scanner,
with
every
single
result
found
on
that
branch,
and
just
this
weird
nested
hell
of
multi
scrolling
within
little
windows.
It's
it's
not
good.
F
A
And
one
thing
that
I've
kind
of
confirmed,
informally
with
a
lot
of
people
but
I,
want
to
say
it
out
loud
to
this
group,
so
you
guys
can
tell
me
if
I'm
wrong.
The
mr
security
information
should
always
be
pulled
from
findings.
It
should
not
be
pulled
from
standalone
vulnerabilities
based
on
the
definition
of
when
a
finding
gets
promoted
to
be
a
standalone
vulnerability.
A
A
A
On
recording
now
so
it
just
maybe
I
mean
I,
don't
know,
we've
actually
formally
had
this
conversation.
I
know
you
know
this
come
up
discussion
of
broth
and
you
know
other
people,
but
over
the
course
of
you
know
six
months
so
just
putting
this
here
on
the
table,
but
Mr
pipeline
view
should
always
be
back
by
findings
based
on
what
the
definition
of
a
finding
versus
a
standalone
vulnerability
is
yeah.
F
F
They're,
just
vulnerabilities,
because
that's
that's
not
really
a
thing
in
the
industry
and
a
finding
is
really
just
something
that
we
have
noticed
in
one
of
the
feature
branches,
and
it
is
not
we're
just
trying
to
flag
something
in
the
Delta
between
that
and
the
target
branch
which
for
right
now
is
always
the
default
branch
master
in
most
cases,
eventually
in
the
future,
we'll
want
to
allow
for
things
like
having
having
that
functionality,
work
for
other
target
branches,
for
instance.
A
lot
of
you
know
big
companies,
especially
if
they
have
a
compiled
applications
desktop
software.
F
They
may
have
their
release
branch
and
then
a
couple
of
older
maintenance
branches,
for
instance.
So
findings
are
just
things
that
haven't
been
merged
into
the
target
yet
and
so
for
the
mr
and
the
pipeline
for
now,
that's
where
they
are.
If
we
want
to
use
this
AV
architecture
under
the
covers.
That's
that's.
None
of
my
business,
you.
E
F
E
Yeah
one
final
note
on
that
issue:
the
EMR
issue:
it's
not
intended
to
be
one
iteration.
It
would
be
great
if
it
could
be,
but
I
kind
of
just
dumped
an
entire
end-to-end
experience
in
there
for
us
to
kind
of
break
down
collaboratively
and
so
whatever
we
need
to
like
pull
out
or
parse
into
a
different
stone.
That's
fine.
F
Yeah,
that's
a
great
point.
We
haven't
really
gone
through
that
exercise
as
a
team,
yet
where
this
is
Andy
and
I
are
kind
of
coming
with
a
particular
thing,
and
we
need
input
on
how
to
slice
it
down
how
to
break
it
down
into
the
NB
C's,
and
so
that's
kind
of
what
this
started
a
conversation
is
here
is
how
can
we
start
chunking
this
out
into
deliverable
pieces,
which
I
mean
this
may
very
well
take
one
to
three
iterations
to
get
all
the
pieces.
E
Happen,
I'm,
probably
not
so
I-
think
13-2
we're
gonna
take
this
into
a
solution.
Validation
with
the
internal
AB,
SEC
team
I
think
it's
still
good
to
like
form
an
opinion
on
how
to
break
this
down,
but
there
may
be
small
changes
happening.
They
were
big
changes.
I
would
be
incredibly
surprised,
but
this
is
recorded.
So
I'll
hold
myself
to
that.
Okay,.
A
A
G
A
A
A
F
I
think
this
one's
a
little
bit
different,
so
what
Wayne
he's
got
captured
there?
It's
when
you
filter
it
down,
it's
actually
misleading.
It
makes
it
look
like.
Even
though
you're
you've
got
vulnerabilities,
you
haven't
configured
the
project
correctly,
so
it's
basically
showing
you
bad
information
when
you
filter
to
a
state
where
the
filter
is
returning,
no
information
or
no
vulnerabilities.
So
it's,
hopefully
this
one's
pretty
straightforward.
It's
just
swapping
out
the
bad
message
for
one
that
actually
makes
a
little
bit
more
sense.
G
So
as
far
as
I
remember,
this
is
valid
for
a
group
and
instance
level
dashboards
as,
as
you
said
it.
If
the
user
has
configured
the
project
and
that
filters
out,
then
we
display
the
message
as
if
they
still
have
been
configured
the
project.
So
probably
we
need
we
just
it.
Just
should
be
just
anything
else,
and
if
the
user
has
configured
projects
and
then
have
no
vulnerabilities,
then
display
this
message
otherwise
display
the
pain
issue,
because
we
we
probably
need
to
keep
this
message
for
the
initial
stains
like
when
the
user
still
haven't
configured.
G
So
it
should
be
just
anything
else.
I
believe
we
have
that
information
that
it's
configured
I
know
I'm.
Sorry,
we
don't
have
that
information,
because
we
need
to
make
a
call,
that's
dynamic,
so
the
server
problem
and
that
will
create
so
we
needed
loading
state,
probably
because
first
we
need
to
display
the
user
that
something
is
loading
and
then,
if
the
project
is
configured
then
display
this
message.
Otherwise
this
may
get
that
message
other
work,
because
right
now
we
default
to
the
to
one
message.
So
we
don't
have
the
loading
state.
G
A
E
G
E
F
To
seems
like
the
mechanism
would
be
the
same,
though,
if
you're
having
to
make
the
call
to
check
and
you're
checking
with
the
filters
applied,
you
would
still
have
that
state
that
something
was
configured,
but
the
current
filter
had
nothing.
It
would
look
stupid
for
you,
as
a
user
to
have
it
configured
to
a
state
where
it
always
just
showed
hey.
Your
filter
has
nothing
here,
but
maybe
I
do
only
want
to
see
critical,
unresolved
and
maybe
everybody's
on
top
of
stuff,
so
the
majority
of
the
time
it's
not,
it
seems
like
it
would.
A
Humans
that
it
might,
there
could
potentially
be
back-end
work
depending
on
whether
we
solve
this
with
some
sort
of
a
loading
or
not
right.
Now,
this
issue
is
only
flagged
for
front-end.
So
if,
as
we're
refining
this,
you
think
that
would
be
a
better
solution.
Let's
make
sure
we
update
this
to
add
the
back-end
label
and
get
some
eyes
from
the
backend
engineers
on
it,
and
also
them
go
ahead.
Try.
G
A
And
then
Andy
are
you
done
with
it
designs
on
this,
because
the
workflow
State
on
this
is
off
so
I'll
update
this
and
put
it
into
refinement
and
since
avouch
has
all
sorts
of
opinions
on
it,
he's
probably
going
to
land
with
this
one
on
his
lap
to
further
refine
and
add
a
weight.
Tiago
and
I
are
working
to
improve
the
definition
of
what's
expected
by
engineers
in
the
refinement
phase
as
part
of
the
feedback
that
we
heard
from
you
guys
during
the
retrospective
so
expect
some
more
communications
around
that.
A
Just
make
sure
that
you
know,
as
I
have
seen
people
do
this
more,
but
as
you're
refining
issues
make
sure
you're
updating
the
problem
description
and
you
know
put
as
much
detail
as
you
can
about
what
you're
finding
during
the
refinement,
not
just
adding
a
weight
to
it
based
on
you
know
what
you
think
should
happen.
That's
not
very
helpful
for
the
next
person,
not
that
you
do
that.
Slash
I'm,
not
targeting
this
at
you
in
any
way,
all
right,
we've
got
two
more
minutes.
A
A
Okay,
so
Matt
mentioned
earlier
that
eventually
we're
just
gonna
have
vulnerabilities
and
they
won't
be
standalone
or
first-class
or
whatever.
So
that
might
affect
how
we
approach
this
issue
that
I
created.
But
one
thing
that
came
out
of
the
standalone
vulnerabilities
retrospective
a
few
weeks
ago
was
the
confusion
of
the
naming
conventions
and
what
we
call
these
things.
A
So
we
decided
at
the
time
to
create
an
issue
to
make
sure
that
we
remove
references
to
first-class
vulnerabilities
in
the
code,
whether
we
replace
that
with
standalone
or
just
refer
that
we
referred
to
them
as
vulnerabilities
I'm,
not
sure,
based
on
other
references
to
the
term
vulnerabilities
in
the
code.
What
makes
the
most
sense
from
a
development
perspective.
So
this
issue
was
around
clean
up
from
the
the
fun
dance
that
we
had
around
terminology
for
standalone
vulnerabilities.
F
G
D
A
Maybe
that's
why
we
pegged
this
as
a
front
end
issue
when
we
talked
about
it
during
the
retro,
because
yeah
we've
all
got
a
drop,
it's
nine-thirty.
If
there
is
back-end
changes,
we
can
either
create
another
issue
or
we
could
encapsulated
in
this.
One
I
wasn't
sure
the
answer
to
that
question
was
either
/.
I.
B
A
A
good
call
out
I'll
add
that
to
a
comments
in
this
issue,
John
thanks
or
at
least
in
the
description.
Not
a
comment
follow
my
own
advice,
all
right,
so
I
don't
know.
If
this
you
guys
feel
like
this
could
move
past
planning
break
down
into
refinement,
or
should
we
bring
this
back
to
next
discussion?
I
see
some
nodding,
heads,
Alexander
and
sabasha
are
not
in
their
heads,
Jonathan
and
Allan.
You
think
you
guys
think
this
is
okay
to
move
on.
I
would
like
someone
from
the
back
end.
It's
to
confirm
that
there's
no
references.