►
From YouTube: Defend: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Defend:Threat Insights group
A
Welcome
to
defends
weekly
threat,
insights
group
discussion,
so
I
hope
everyone's
had
a
chance
to
look
at
the
agenda.
There
was
a
lot
of
great
demos
shared
that
I
would
hope
that
everyone
looked
at
in
advance
because
we're
not
going
to
spend
time
looking
watching
them
as
a
group.
So
please
do
so
after
the
call
of
you
haven't
had
a
chance
to
let's
jump
right
in
to
our
top
agenda
item,
which
is
follow-up
from
previous
discussions.
So
Jonathan
you
were
looking
into
breaking
changes.
I
believe
that's.
B
Right
yeah,
the
main
I
thought
I
was
looking
for
was
on
that
API
and
that
we
were
that
issue
and
looked
like
we
were
doubling
up
and
that
that
got
overwritten
by
another
change.
So
that's
no
longer
in
place,
that's
know
so
yeah
everything
is
either
an
on
or
off
so
it
looks
like
we
should
be
good
good
to
go.
A
C
A
Let's
get
to
that
one
breaking
changes,
meaning
that
we
are
providing
functionalities
functionality
to
our
customers
today
that
we
will
be,
you
know,
requiring
extensive
updates
from
them
to
continue
using
like
if
we
were
to
I.
Think
the
one
example
that
came
up
so
far
was
that
we
were
gonna
change.
The
name
of
an
API,
so
customers
who'd,
be
using
that
API
directly
would
need
to
be
informed
of
that,
so
they
can
update
their
references
to
it.
So
we
try
and.
A
Of
yeah
yeah,
so
what
you're
talking
about
swashes
is
new
development
and
I'm
wanting
to
get
to
that
and
I'm
concerned
about
it.
So
because
it
is
one
of
the
items
that
is
being
tracked
as
part
of
our
1210
goals
for
a
customer
so
I
will
we
remain
nameless
for
anonymity,
sake,
okay,
but
good
clarification.
So
again,
breaking
changes.
I
think,
there's
a
link
in
this
agenda
somewhere
of
how
that
is
defined
and
why
we
put
it
in
two
major
milestones
like
13
dotto.
A
So
the
next
agenda
item
I
added
Sam,
went
on
lead
for
a
week,
so
he's
out
this
week
and
he's
been
working
very
closely
with
siwash
and
with
Ohio
VL.
Thank
you
for
joining
us
and
he
gave
us
a
very
thorough
word
document
that
is
linked
to
down
in
the
the
demo
part
of
this
agenda,
as
well
as
a
video
demo
of
the
progress
that
he's
made.
A
So
after
going
through
that
document
and
the
feedback
from
Sam
the
one
item,
that's
really
jumped
out
as
a
feature
that
we
had
previously
said
was
sort
of
a
stretch
or
a
nice-to-have
to
NBC,
but
over
the
course
of
the
last
couple
of
weeks,
matt
has
had
new
information
come
to
him
around
problems
that
this
could
create.
So
this
is
around
supporting
multiple
dismissals
of
a
vulnerability
on
the
dashboard
page.
It's
something
that
was
added
to
the
security,
dashboard
and
I.
A
E
So
it's
it's
kind
of
a
an
interesting
quirk
of
timing
and
a
byproduct
of
what
we're
going
to
be
doing
with
the
first-class
vulnerabilities.
So,
if
you
haven't
been
following
some
of
these
issues,
there
is
a
is
an
interesting
I
think
what
is
technically
a
defect
but
seems
like
a
feature
specifically
with
dashed
bindings.
The
way
that
they
behave
today
is,
if
you
dismiss
one
desk
finding
that
has
that's
tagged
with
a
particular
identifier,
which
is
the
CVE
field.
In
the
current
json
reports.
It's
not
actually
a
CDE
number.
E
It's
just
kind
of
a
anything
goes
in
there
well
for
DAST.
It
is
putting
in
it's
just
a
number
that
identifies
the
particulars
app
module
that
detected
it
when
you
dismiss
something
from
a
dashboard.
If
it
is
a
DAST
detection,
everything
that
shared
that
same
identifier
gets
dismissed
now.
The
reason
why
that
seems
like
a
feature
is
that
DAST
is
one
of
the
noisier
scanners
and
will
often
produce
multiples
of
the
same
type.
Finding
there
won't
be
a
way
to
quickly
kind
of
get
rid
of
a
lot
of
this
noise
for
customers.
E
If
we
were
to
still
have
the
multi
select,
it
would
at
least
give
users
the
ability
to
sort
of
quickly
do
use
the
basic
filters
and
dismiss
pages
of
them
at
a
time
by
moving
to
the
first-class
vulnerabilities.
My
understanding
is
that,
because
we
are
now
tracking
everything
in
the
database,
that
behavior
is
going
to
go
away
anyway
for
DES.
So
it's
going
to
be
you,
you
select
one,
you
dismiss
one,
so
we're
we're
taking
it
from
accidental
bulk
dismissal.
E
You
have
to
now
drill
in
individually
to
each
page
for
vulnerability,
so
the
net
result
is
it's
going
to
make
the
workflow
much
less
efficient
for
people,
and
it's
going
to
be
really
really
painful
until
we
can
get
a
this
multi-select
functionality
back
out.
So
this
is
kind
of
the
fallback
because
of
the
change
in
the
behavior.
E
E
It's
just
it's:
it
was
what
was
selected
to
back
that
particular
scan
type,
and
it
is
gassed
in
general,
can
tend
to
be
kind
of
noisy
for
things
like
that.
So
I'll
give
a
really
specific
example
that
I
was
given
that
I
liked
so
because
it
is
doing
dynamic
scanning
against
your
running
application.
Let's
say
that
you
had
a
misconfigured
header,
every
single
request
that
the
desk
scanner
tries
to
make
for
every
end
point
for
every
parameter.
Change
is
going
to
give
you
that
same
header
error.
If
you
make
5,000
different
requests,
you
get.
E
Five
thousand
of
the
same
error
got
it,
which
is
like
a
real
thing
with
the
desks
scans
today.
So
before
a
few
dismissed
one,
the
other
4999
would
just
magically
disappear.
Technically,
that
is
a
defect,
but
you
can
see
how
now
going
from
that
model.
To
you
don't
even
get
the
modal
to
dismiss.
You
actually
have
to
click.
You
will
go
into
an
individual
page.
You
would
have
to
look
at
it.
Dismiss
that
come
back
out,
that's
going
to
be
very
problematic,
so
at
least
the
multi
dismiss
would
let
you
you
know,
take
care
of.
G
A
For
the
sake
of
time,
then
getting
to
all
of
our
agenda.
Let's
keep
talking
about
this,
but
move
forward.
Alexander
has
been
looking
at
this
from
a
UI
perspective
front,
end
perspective,
and
there
is
back-end
work
associated
with
this
as
well
so
I
know,
we've
already
got
our
plates
really
fully.
I
think
we
need
to
be
really
realistic
about
whether
this
additional
work,
as
well
as
some
of
the
other
challenges
that
we've
been
encountering
over
the
course
of
the
development
of
this
milestone.
A
We're
gonna
have
to
start
to
discuss
what
we
can
shave
off
or
what
we
can
realistically
deliver
in
1210
I.
Don't
want
to
say
this
with
looking
at
Kyla's
face
in
the
video
and
potentially
we
had
to
move
this
to
13
data,
what
that
would
mean.
So
that
is,
you
know,
a
scenario
we
want
to
try
and
avoid,
but
again
that's
where
we
at
right
now
so
alex'
it
there.
Any
questions.
C
A
H
G
No
I
think
that
is
a
plan
and
it
looks
like
the
initially
I
was
thinking
would
need
to
have
a
new
graph
Kiyomi.
They
didn't
know
that
we
had
a
dismissal
for
a
rush
to
employ
dismissal
for
vulnerability,
stand
alone.
Vulnerabilities
I
thought
we
only
had
one
for
findings,
but
it
looks
like
from
item
1a
here
that
we
do
have
a
dismissal
rest
endpoint
for
standalone
vulnerabilities.
Is
that
correct?
That's
great,
awesome!
Okay!
So
in
that
case,
adding
a
project
fingerprint
to
the
existing
vulnerability,
Graciela
schema
is
pretty
trivial.
G
A
F
I
have
yell
Rob.
The
main
point
of
the
the
rest
in
point
does
exist
and
that
the
graph
QL
schema
currently
in
place
to
give
ulnar
abilities
returns.
The
report
type
the
ID,
though
not
what
the
endpoint
like
expects
from
the
IDs,
so
there's
a
little
bit
of
modification
there,
but
the
project
fingerprint
is
the
most
important
thing
that
I
am
missing.
F
That
I
can
tell
at
this
moment,
for
this
endpoint
to
be
able
to
dismiss
for
all
abilities,
so
that'd
be
great
to
get
back,
but
then
otherwise
I've
just
been
sort
of
hacking
and
slashing,
and
that
there's
a
nice
little
little
screenshot
up
there
of
what
I've
got
so
far.
The
check
boxes
seem
to
be
working.
It's
just
that
dismiss
button.
It
doesn't
do
anything
yet
in
time.
C
C
A
It
sounds
like,
despite
this
new
addition
scope
for
this
release,
that
you
guys
are
jumping
on
this
right
quickly
and
we're
able
to
find
paths
forward
that
are,
you
know,
potentially
gonna
require
us
to
come
back
and
revisit
this
in
a
future
iteration
but
they'll.
Let
us
move
forward
with
the
least
amount
of
effort.
You
know,
I.
Think
ivlu
also
brought
up
the
concern
around
the
the
pace
of
getting
things
reviewed.
I
know
that
you
were
speaking
from
the
back
end
at
that
time,
but
I
don't
think
it's
specific
to
just
the
back
end.
A
E
A
Believe
the
answer
is
yes,
but
I'm
not
sure
if
the
customer
that
we're
targeting
is
self
hosted
or
not,
because
that
would
be
the
big
constraint
there
so
I,
you
know
we
released
a
production
for
customers
on
Comm
I.
Think
twice
a
week
was
what
we
just
discussed
in
the
staff
meeting
yesterday.
It
would
just
be
and
I
think
we
talked
about
this
with
a
smaller
group
that
the
customer
we're
talking
about
is
self
hosted,
so
they'd
only
get
the
monthly
rollouts
of
updates.
I,
don't
know
if
there's
a
way
with
that
particular
customer
I.
E
The
the
reason
I
was
just
inquiring
is,
if
it's
a
matter
of
letting
them
know
they
can
pull
the
you
know
the
the
12:10
release,
but
then
watch
out
for
this
particular
update
being
very,
very
clear
what
would
come
in
a
subsequent
I?
Don't
know
we
refer
to
those
as
patch
releases
incremental
releases.
That
may
be
acceptable
for
some
of
these
things
that
are
technically
parity
features.
A
A
I'm
not
sure
on
the
get
lab
process
of
patches
how
self-hosted
customers
get
those
types
of
updates
and
how
frequently
so
we
can
work
on
finding
that
answer.
For
that
I,
don't
know
Wayne
or
anyone
else
on
the
call
have
yell
anyone
have
any
insight
into
that
so
give
it.
Anyone
who's
been
here
longer
than
me.
Oh
I,.
A
Obeah
you'll
update
this
issue
that
you
created
yesterday
to
reflect
the
change
in
direction
from
a
back-end
that
we
described
yeah
great
and
yes,
it's
a
good
reminder
that
you
know
these
items
that
were
sort
of
putting
off.
We
should
be
creating
future
issues
to
make
sure
that
we're
tracking
them
I
know
I
created
a
number
of
those
yesterday
that
we'll
be
reviewing
with
that,
hopefully
targeting
thirteen
dunno.
But
this
is
another
example.
So
thanks
audio
okay,
I
love
the
pre-recorded
demos.
This
is
fantastic.
A
F
Yeah
siwash
in
Sam's
video,
sorry
I'm,
asking
you
about
Sam
sale
in
Sansa.
Here
he
was
talking
about
the
difference
between
like
the
project,
the
group
and
the
instance
dashboard,
and
the
work
on
each
of
those
currently
for
the
multi
dismiss
I
have
done
it
on
the
project
dashboard.
Will
it
be
easily
replicated
on
the
other
two
because
I
see
the
other
two.
Currently,
a
master
are
not
using
graph
QL
before.
A
You
answer
that
question
service.
Is
it
required
on
those
other
two
dashboards
that
we
talked
about
this
yesterday
and
I
thought?
With
the
very
least
for
this
MVC
we
were
gonna
target
the
project
level
dashboard,
but
adding
the
multi
dismissal
to
the
instance
and
the
group
dashboards
was
not
as
urgent
I
would.
A
F
C
So
I
as
far
as
I
know,
so
we
are
done
with
the
project
project
dashboard,
it's
it's
a
master
master
and
then
I'm
working
on
the
group
word.
It's
gonna
be
merged
as
soon
as
the
pipeline
gets
green,
so
I
got
the
approval
and
then
there
is
this
instance
level
which
I
started,
but
yet
not
yet
submitted
the
the
merge
request.
But
so,
if
we,
for
instance,
for
the
filters
we
have
a
reusable
component
and
if
I'm
adding
that
it's
a
trivial
work
to
multiple
dashboards.
C
C
A
A
C
So
I've
been
working
on
this
for
for
a
month
now,
I
finally
got
them
are
approved,
but
then
today
I
realized
that
so
with
the
latest
changes.
Now
we
have
two
dashboards.
One
is
the
graphical
dashboard
and
then
the
other
one
is
the
old
REST
API
dashboard,
and
this
button
was
added
for
the
old
one
so
for
the
REST
API,
which
means
that
as
soon
as
we
remove
the
feature
flag,
it's
not
going
to
be
visible
anymore.
To
my
understanding
and
it's
not
working
properly
from
the
backend
side
at
least
the
current
branch.
C
It's
not
working
properly,
because
the
moment
I
am
a
disabled
official
track.
The
first-class
vulnerabilities
feature
flag.
First
of
all,
there
is
no
way
for
me
to
get
the
button
because
it's
the
new
dashboard
that's
been
displayed
and,
second
of
all,
it's
using
the
REST
API
the
button
itself.
So
it's
the
old
endpoint
that
works
and
the
back-end.
For
some
reason
it
doesn't
work
when
the
feature
flags
is
disabled.
So
there
is
I.
Think
there's
a
confusion.
Here
was
that
I,
clear
or
your.
A
Explanation
was
clear
too
me,
so
this
is
work
that
we
started
with
two
brand
new
developers
when
things
were
very
influx
in
this
dashboard.
So
this
was
a
risk
we
knew
we
were
entering
when
we
we
started
working
on
this
download
and
it
sounds
like
it
went
the
worst
direction.
So
you
know
exposing
the
button
on
the
other
side
of
the
feature
flag
from
a
UI
perspective.
Prick
me
wrong
that
that's
not
a
huge
change.
A
It's
getting
your
MRI
out
there
and
approved
again,
but
then
investigating
the
problems
that
you
were
seen
with
the
data
that
was
actually
part
of
that
export
under
the
new
first-class
vulnerabilities
object
model.
That's
where
the
bigger
risk
lies
right,
well,
I,
don't
say
bigger
because
again
that
risk
of
getting
an
MRI
push
through
is
substantial,
but
am
I
understanding
that
correctly
/
yeah.
C
That's
correct
so
I
didn't
know
if
I
go
if
I
need
to
go
ahead
and
then
use
the
button
in
the
new
dashboard
or
because
we
include
that
kind.
Yes
good.
So
if
if
we
include
that
I'm
not
sure
that
I
think
the
backend
uses
the
old,
so
it's
not
using
graph
chaos,
so
I'm,
not
sure
if
those
are
connected,
so
we
might
be
exploiting
different
data
because
we're
not
using
graphic
UL
for
exporting
the
data
am
I
correct.
D
C
I
I
A
A
date
that
has
been
it
for
conversation
and
I
believe
that
it's
usually
two
days
before
and
I,
don't
think
it's
a
week
day
type
thing
for
as
far
as
I'm
concerned,
I
thought
it
was
going
to
be
the
nineteenth,
but
we
can
confirm
that
lvl
Philippe.
Do
you
guys
have
any
historical
knowledge
of
when
to
expect
that
date
to
land
on.
G
A
I
Okay,
that's
the
seventeenth.
We
know
it
takes
a
related
days,
very
Mars
to
be
merged,
so
that's
making
sure
I'm
getting
my
days
of
the
week
right
and
doing
my
date
math
correctly.
So
that's
for
ten
lens
for
10
this
week,
Friday!
So
not
all
mrs
takes
seven
days.
Some
take
longer.
Some
take.
You
know
to
be
merged
once
initially
since
so,
and
we
can
also
when
submitting
the
mrs,
the
closer
we
get
to
410
the
more
we
should
comment
to
the
reviewers
and
the
maintainer
to
hey.
This
is
really
important
for
1210.
Here's.
I
The
reason
why
you
know
given
the
link
to
the
issue
tracking
the
customer
need
just
so
they
know
it
and
you
know
also
reach
out
to
people
via
slack
as
needed
after
we've.
Given
them,
you
know
two
business
days
yeah
so
I'd
like
to
do
is
just
go
around
I
know
we
don't
everybody
on,
but
for
the
changes
they
that
are
critical
for
first-class
poems
and
for
vuln
export.
I
C
Have
the
group
Burt,
that
is,
that
is
merge,
but
waiting
for
the
pipeline
to
be
green
and
then,
as
soon
as
that
goes
live
that
goes
on
master
I
have
two
small
changes:
adding
the
well
the
filter
and
then
the
the
vulnerability
count,
but
that
should
be
a
trivial
job
and
then
I
can
start
working
on
the
instance
level
so
and
for
the
instance
level
I
could
submit
something,
but
there
I
think
I
depend
on
the
back
end.
The
back
end
needs
to
provide
me
the
query
for
right
for
acquiring
the
instance
level
vulnerability.
D
G
G
So
project
dashboard
I
think
should
have
everything
except
multi
justness,
which
I
should
have
NMR
for
by
Friday
group
dashboard
history,
we're
saying
it's
not
MVC,
so
it
should
have
everything
else
merged
already
again,
except
multi
dismiss
and
the
instant
dashboard
gosh.
This,
mr
has
been
in
review
for
like
two
weeks,
and
it
has
just
been
such
a
slow
cycle
getting
people
to
review,
but
it
is
already
in
review,
which
means
that
it
is
at
least
in
review
before
Friday,
so
I'd
say
everything
is
in
a
good
place
right
now.
Okay,.
B
A
B
Sorry
take
it
back
in
about
an
hour
once
the
pipeline
finishes
running
to
make
sure
it
all
goes
any
others
on
your
plate.
Currently
that
are
critical
for
fcv.
Nothing,
critical,
I
think
I've
got
one
more
issue
out
there
for
me,
but
that's
just
kind
of
a
refactor
more
than
anything
else.
So
it's
not
critical
to
get
MPC.
Okay,.
I
A
C
C
I
Know
Ross
couldn't
make
it
today,
but
Ross's
I
think
on
track
on
the
database.
Merge
one
there's
a
discussion
later
today
with
the
database
reviewers
a
bit
of
a
lot
of
feedback
from
the
database
maintained
or
a
lot
of
feedback
from
the
maintainer
and
Daniel.
You
know
it.
This
is
not
a
good
time
for
him,
so
you
know
Staniel
later
so
it
sounds
like
we're
we're
getting
close
there.
Some
things
may
slip
past
that
and
we'll
deal
with
that
as
appropriate
and
probably
try
to
speed
up
the
review
and
maintain
process
on
them.
A
Os
Daniel
to
update
us
in
that's
right,
insights
room
around
his
progress
because
he
has
been
very
focused
on
the
standalone
page
and
I.
Don't
want
to
leave
him
stranded
there
I,
don't
know
if
Alexander
or
Alan,
who
have
both
been
contributing
to
conversations
around.
You
know
supporting
the
work
that
he's
doing
there.
If
you
guys
have
any
insights
into
blockers
or
progress
there
to
share,
but
unfortunately
about
Daniel
here,
we'll
just
let
him
share
this
I
think.
I
We're
a
little
over
on
time,
but
that's
okay,
so
so
probably
good,
maybe
maybe
skip
six
and
seven
but
a
vo.
Do
you
want
to
give
the
FYI
on
your
item
I?
Think
it's
another
important
one
yeah.
G
So
when
we
discovered
that
the
feature
flag
we
have
for
the
first
class
vulnerabilities
in
graph
QL,
we
can't
turn
on
for
one
specific
project.
I
found
a
workaround
for
that,
but
got
blocked
because
there's
I
found
a
bug
in
our
graph
QL
off
logic
and
I've
been
talking
with
the
Garfield
team
on
how
to
test
the
fix
I
have
for
it.
I
Except
you
so
we're
over
by
two
minutes:
I
guess
we'll
discuss
issues
to
plan
and
breakdown
which
nobody's
ready
to
start
on
those.
Yet
anyway,
everything
else
going
on
it's
good
to
be.
You
know,
thinking
in
advance
and
Tiago,
we'll
talk
about
timeframes
for
the
meeting
next
week.
Don't
worry
about
it!
Good
stuff,
thanks
everybody.