►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
Welcome
to
our
weekly
threat
insights
group
discussion,
I
remembered
to
add
the
accomplishments
to
the
agenda,
because
that
happens
once
in
a
while.
So
there's
a
through
f
listed
there
and
we
have
one
community
contribution.
So
that's
exciting
we're
discussing
moving
these
accomplishments
from
the
weekly
group
meetings
into
the
bi-weekly
staff
meeting
the
threat
management
sub
department
level
staff
meeting,
because
it
means
we
have
to
run
this
query
less
often
and
we
get
to
share
across
groups.
A
I
feel
like
this
create
jira
issue
from
vulnerability.
Oh
yeah,
okay,
so
allen
added
here
saying
that
the
back
end
work
is
ready
to
be
reviewed
and
merged
for
the
issue
creation.
There's
any
discussion
needed
how
to
integrate
this
with
the
front.
End
he's
happy
to
help
so
daniel
hi.
Welcome
to
the
call
daniel's
going
to
be
working
on
the
front
end
for
this.
I've
asked
him
to
take
a
look
at
the
work
that
alan's
done
around
the
spike,
which
included
the
implementation
plan.
A
I
was
a
little
bit
confused
when
alan
started,
creating
issues
that
represented
all
of
the
work
from
his
implementation
plan
or
just
the
back-end
and
database,
which
is
what
it
looks
like
so
daniel
we'll
be,
I
believe,
creating
the
front
end
issues
that
are
required
for
that.
I'm
also-
and
I
think
matt
is,
in
a
similar
place,
a
lot
of
this
allen's
already
built
so
trying
to
figure
out.
A
You
know
he
has
this
great
demo
that
he
shared
with
us
and
a
psc
and
a
video
so
figuring
out
what
still
actually
needs
to
be
implemented
for
that.
As
part
of
the
challenge,
daniel.
B
A
We've
got
some
demos,
savage
is
in
here,
but
we
merged
the
he
merged
the
mr
for
introducing
the
new
vulnerability
trends
chart,
which
also
includes
the
navigation
changes.
So
it
takes
the
vulnerability
list
at
the
project
level
and
puts
it
on
its
own
vulnerability
list
page
and
creates
a
cool
new
trend
chart
to
show
vulnerabilities
over
time
at
the
project
level.
C
We
could
we've
been
using
the
sparklines,
I
think
as
a
proxy.
I
think.
Eventually,
we
want
to
go
there
matt,
and
I
were
talking
about
like
a
new
list
of
metrics
to
start
getting
designs
for
so
that
could
be
included.
C
D
D
The
biggest
challenge
is
going
to
be
getting
everyone
to
stop
saying
security
dashboard
when
they
mean
vulnerability
report,
because
that
is
where
it
started,
and
people
still
kind
of
use.
Those
terms
I
will
even
play
along
just
to
not
confuse
people,
but
I
think
it'll
actually
be
really
helpful
to
have
dashboards
or
for
dashboardy
stuff.
The
vulnerability
report
is
where
you
see
the
list
do
and
we'll
have
that
in
all
the
places
yeah.
C
It
might
actually
be
also
helpful
with
the
other,
secure
teams
to
say,
like
project
level,
vulnerability
report,
because
I
know,
there's
vulnerability.
Report
means
something
else
like
the
sassed
vulnerability
report.
I
think.
D
A
D
Oh
sorry,
to
go
back
to
the
first
point:
quick
plug
slash
request
bag
for
daniel
as
you're
working
through
the
jira
stuff.
Any
screenshots
of
the
new
stuff
would
be
extremely
helpful.
B
A
Cool,
thank
you
all
right.
So
alan
rhonda
allen
ran
with
a
suggestion
yesterday
and
implemented
a
better
version
of
our
special
references.
You
know
we
played
around
with
using
the
plus
sign,
but
that
created
some
links
to
vulnerabilities
that
were
not
intentional
in
places
like
increases
of
size
on
the
mr
reports.
A
So
we've
reverted
that
and
we
have
implemented
what
he's
sharing
here.
So
this
is
pretty
cool.
It's
just
the
brackets
for
the
word:
vulnerability,
colon
id
and
andy.
Is
this
something
that
they're
looking
to
adopt
in
other
parts
of
the
product?
Besides
vulnerabilities
and
sort
of
a
new
syntax
for
special
references.
C
Maybe
the
alerts
that
are
coming
from
the
manage
team.
D
Can
actually
speak
to
that?
It's
not.
He
didn't
link
it
here.
There
was
actually
an
issue.
That's
been
going
on
for
a
few
months
about
how
to
do
this,
get
lab
wide
and
it
looks
like
the
conversation
actually
went
in
direction.
I
wasn't
expecting,
which
is
moving
all
references
to
all
object,
types
and
events
over
to
this
new
model,
and
I
don't
know
what
the
transition
plan
looks
like
for
things
like
issues
and
mrs
other
than
to
support
both,
but
this
seems
to
be
the
chosen
syntax
for
everything
going
forward.
D
Well
and
because
you
have
to
know
all
of
the
different
special
reference
characters
for
each
different
type,
that
gets
kind
of
confusing
and
can
be
frustrating
so
this
is.
The
initiative,
looks
like
eventually
over
time,
they're
going
to
add
both
new
ones
and
existing
ones
to
this
format
we're
just
first,
since
we
were
trying
to
get
ours
in
and
we
ended
up
with
a
problem
with
the
plus
sign.
So
we
kind
of
got
blocked
on
it,
and
it
was
just
made
sense
to
push
forward
once
the
decision
is
more
or
less
made.
B
The
custom
scanner
stuff,
but
my
local
is
currently
broken.
E
And
I'll
have
one
for
next
week
as
well,
that
that
intermittent
intermediate
screen
between
creating
an
issue
for
vulnerability
and
being
able
to
edit
it
so
I'll
be
able
to
go
to
create
issue
screen.
First.
A
A
So
alan
had
a
suggestion
around
how
to
break
this
down,
and
I
think
we
discussed
quite
a
bit
the
undo
versus
the
confirmation
and
we
have
buy-in
for
moving
forward
with
a
confirmation
instead
of
an
undo
so
that
takes
away
some
of
the
complication
from
the
back-end
perspective.
A
Andy,
we
still
need
some
mocks,
especially
with
the
texts
and
stuff
I
mean.
Clearly
we
can
get
started,
but
yeah,
okay,
okay,
savash,
is
going
to
be
working
for
the
front
end.
Part
of
this
is
the
dri
for
planning
breakdown
right
now.
Alexander.
Is
this
milestone
supposed
to
be
focused
on
container
security?
We're
happy
that
he's
here,
but
in
general
I'm
not
asking
him
to
be
the
dri.
A
A
Vision
for
bulk
updates
and
there's
just
some
sort
of
questions
about.
Does
it
make
sense
to
you
know,
take
care
of
one
versus
the
other
first,
I
know
andy
put
forth
a
really
good
suggestion
around
like
let's
get
these
dismissal
types
updated
and
added
to
all
the
different
locations
and
then
come
through
and
change
the
way
the
bulk
updates
handle
both
dismissal
types
and
comments.
Thiago
had
a
very
different
approach,
but
it's
unfortunately
not
able
to
join
the
call
today.
A
So
we're
kind
of
in
this
limbo
right
now
figuring
out
how
to
approach
this.
Do
we
want
to
take
a
look
at
thiago's
suggestion
as
a
group
and
see
if
that's
how
we
want
to
move
forward,
as
opposed
to
both
of
those
two
suggestions,
I'm
happy
to
share
in
the
meeting.
If
you
guys
want
to
see
it
or
you
can
click
on
the
link
that
he
added
in
the
agenda.
C
Yeah,
I
wasn't
following
too
much
of
what
tiago
was
saying
and
the
proposal
I
put
down
was
trying
to
meet
the
need
of
not
removing
that
aspect
of
dismissal
which
matt
you
mentioned
was
like
a
minor
concern,
but
like
it,
it
really
just
depends
on
how
things
shake
out.
So
I'm
I
can
go
either
way.
A
And
a
lot
of
this
is
based
on
thiago's
troubleshooting
around
how
this
is
working
today-
and
I
don't
know-
maybe
you
know-
between
danielle
and
alexander
and
jonathan,
if
you
guys
have
insights
into
this,
but
it
looks
like
today
we're
taking
the
dismissal
reason,
that's
set
during
the
bulk
dismissal
and
basically
using
the
comment
field
to
capture
that
and
there's
some
question
of
whether
we're
actually
capturing
the
value
that's
set
in
the
bulk
dismissal.
Like
the
reason
for
dismissal
today
making
sure
those
are
two
separate
fields.
B
Oh
yeah,
so
currently
right
now,
it's
the
reason
that
you
pick
is
like
a
preset
comment
that
gets
added.
So
we
don't
have
the
the
dual
like
a
reason,
a
reason
code
and
then
a
recent
comment.
It's
just
a
comment
right
now.
A
So
I
think
that's
what
we've
identified
as
the
bigger
back
end
work-
that's
needed
here,
maybe
even
the
only
back
end
work,
that's
needed
here
now
that
we're
not
moving
forward
with
the
undo.
I
did
talk
to
savash
about
this
this
morning.
He's
not
happy
with
the
fact
that
what's
happening
is
that
the
front
end
is
calling
you
know
for
each
vulnerability,
that's
being
dismissed.
A
It's
making
a
separate
api
call
out
to
dismiss
that
and
thought
there
was
an
opportunity
for
some
optimization
there,
especially
from
a
performance
perspective
to
you
know,
send
sort
of
the
payload
up
to
the
api
saying
you
know
here
are
the
50
or
100
or
x,
number
of
vulnerabilities
and
the
details.
You
need
to
dismiss
it
and
do
it
in
one
call
versus
30
or,
however,
many
vulnerabilities,
you're,
you're
changing
the
status
of
so
that
could
result
in
some
that
can
work
as
well.
E
This
is
this
would
be
a
graphql
route
correct,
so
I
mean
we
could
just
send
a
an
array
of
vulnerability
ids,
so
it
shouldn't
be.
That
should
fairly
be
a
fairly,
I
think,
fairly
simple
route
to
implement.
F
I
I
haven't
looked
in
the
code
in
a
while,
but
I
think
I
remember
that
it
is
true
that
we
send
a
request
for
every
single
vulnerability
to
dismiss,
but
that
we
have
some
graphql
magic
on
the
front.
End
that
batches
all
the
requests
that
happen
within
10
milliseconds
into
a
single
one.
F
And
so
I
believe
that
catches
about
12
at
a
time
which
is
better
than
nothing-
and
I
am
not
I'm
not
sure
if
there's
gonna-
be
that
much
performance
improvement
by
like
creating
a
new
endpoint
to
batch
them
all
into
one.
But
I
have
to
verify
that
again.
E
So
quick
question
on
this:
if,
when
implementing
this,
if
for
some
reason
one
of
them
fails
to
to
change
to
change
the
the
state,
do
we
want
them
all
to
fail,
or
do
we
want
to
make
the
ones
succeed.
B
That
need
to
succeed,
so
I
can
speak
to
that
because
I
fixed
that
problem
so
because
we're
doing
an
individual
query,
we
also
get
individual
responses,
so
we
are
currently
processing
it
as
if
you
do
10-
and
you
know
like
three
fail:
you'll
get
seven
success,
messages
or
a
message
that
says:
seven
succeeded
and
then
an
error
that
says
you
have
something
that
failed.
B
So
we
just
to
speak
to
what
alexander
said.
I
did
see
the
batching
too,
but
in
my
instance
it
batched
it
by
four
at
a
time
instead
of
twelve.
So
that
might
be
something
that
we
just
wanna
keep
for
now,
unless
we
want
to
do
some
custom
error
messaging,
where,
if
you
do
ten
as
a
bulk,
then
you'll
get
like
the
response
will
tell
you
which
one
succeeded
which
one's
failed.
E
All
right
so
best
best
effort,
so
the
best
effort
on
that.
Okay,
I'll
put
a
note
in
that.
B
A
A
It
doesn't
even
touch
on
this
question,
though,
of
sort
of
the
order
and
how
we
implement
this
so,
like
I
said,
andy's
got
some
suggestions
around
sort
of
cleaning
up
around
how
we
deal
with
the
dismissal
reasons
first
and
then
adding
the
milk
dismissal
after
that,
because
we'll
have
all
the
right
reasons
in
all
the
right
places,
thiago
kind
of
countered
that
I
think
it
has
to
do
with
this
technical
consideration
of
how
we're
storing
the
reason
versus
the
comment
today.
A
So
if
you
guys
could
take
a
look
at-
and
I
don't
think
we
need
to
answer
this
in
this
call-
I
think
you
got
anyone
who
has
an
opinion
can
share
this
as
a
comment
in
the
issue,
but
savash,
like
I
said,
savage
will
be
the
person
from
the
the
front
end.
A
That's
working
to
break
this
down
and
I
don't
know
if
we
have
anyone
currently
on
the
back
end
who's,
putting
attention
to
this
and
we'll
be
doing
that
so
can
we
do
you
think
it's
premature
to
ask
our
planning
breakdown
questions
of
this
effort
right
now,
I'll
go
through
them
quickly?
A
Are
the
requirements
clear
enough
to
understand
the
intent
of
the
request,
even
after
the
changes
that
we've
talked
about
and
to
add
andy
and
matt,
have
we
updated?
Can
we
update
the
issue
to
reflect
the
confirmation
versus
some
of
the
decisions
that
we've
been
making
as
part
of
these
discussions?
I'm
happy
to
do
it
or,
if
you
guys
want
to
yeah.
A
A
A
E
A
All
right,
so
I
don't
hear
any
big
names
so
we're
moving
on.
Do
we
understand
the
dependencies
of
the
work
to
be
accomplished?
Is
there
I
mean
we
understand
that
there's
a
database
change
and
how
we
store
the
reason
versus
the
comment,
but
is
there
anything
outside
of
threat
management
or
threat
insights
that
needs
to
be
considered.
A
Nope,
I
thought
we
removed
this
question.
Why
didn't
that
save?
Oh,
I
mean,
since
I
switched
over
to
a
different
agenda
and
I'm
reading
it
off
the
container
security
agenda.
Now,
okay,
is
this
small
enough
to
complete
in
one
iteration
if
we
were
ignoring
anything
else,
we
might
have
in
an
iteration
and
we
are
focused
on
this:
do
we
believe
that
we'd
be
able
to
get
this
done
in
one
milestone.
A
A
We
want
to
some
question
for
this
end-to-end
testing
I
feel
like
this
is
one
that
having
will
have
some
attention
on
and
make
sure
that
if
there
are
undone
tests
that
they're
not
breaking,
and
if
there
aren't
you
can
decide
if
there's
coverage,
that's
needed
there.
Does
anyone
disagree
with
that.
A
Here
so
cool,
that's
great
any
opinions
I
mean,
please
read
thiago's
approach
versus
andy's
approach
and
we
need
to
decide
how
to
move
forward
with
kind
of
the
dependencies
between
those
two
issues.
C
So
no
way
the
ultimate
end
step
for
the
bulk
update
is
to
get
the
same
dismissal
reason
drop
down
or
similar
to
into
the
bulk.
That's
similar
to
what's
on
the
vulnerability
page
end
state.
C
C
If
you
have
dismissals
hidden,
you
don't
get
that
this
happened
thing
right
as
a
user,
so
they
actually
are
hidden
from
the
ui
and
kind
of
go
about
it
and
you're
like
wait.
Did
that
work?
So
that's
why
we
originally
had
the
toast
to
kind
of
say,
yep,
your
six.
Your
action
was
successful.
C
The
undo
is
kind
of
a
very
nice
to
have.
If
it's
not
a
toast,
it
could
be
an
alert,
but
we
need
some
perhaps
some
way
to
reaffirm
that
the
action
that
the
user
had
taken
was
successful.
B
Currently,
if
you,
if
you
don't,
have
the
dismissed,
filter
selected
and
you
dismiss
vulnerability,
it's
removed
and
you
get
the
toast,
but
no
no
undue
functionality.
C
A
A
My
head,
it
wasn't
a
pop-up,
it
was
sort
of
like
a
line,
but
whatever
you
decide,
yeah
right,
okay
in
the
design
issue,
I
I
I'm
assuming
you've
got
it
in
your
design.
Images
andy
that
we
will
persist,
that
modal
or
sorry
to
pop
up
the
toast
that
we
have
today.
That
says
you
have
dismissed
x,
number
of
vulnerabilities
but
it'll
apply
to
all
the
status
changes.
A
Okay,
did
you
did
your
question
get
answered?
Andy
the
original
one,
yeah,
okay,
we're
kind
of
at
the
end
of
the
call.
We
never
seem
to
get
past
this
one
issue.
It's
good,
though,
because
we
did
start
to
talk
about
the
dismissal
types
and
reasons,
and
you
know
these
are
closely
related.
So
do
we
we
have.
A
A
Well,
I
I
think
we
have
decided
that
the
bulk
update
for
the
dashboard
that
the
first
issue
4a
has
passed
planning
breakdown.
There
is
some
questions
about
how
we're
going
to
do
that
breakdown,
but
we
haven't
agreed
about
that
with
4b
and
the
dismissal
types
and
reasons,
because
it
is
a
little
bit
more
than
just
changing
what
values
are
in
the
drop
down.
It
also
includes
adding
those
dismissal
types
to
the
modal.
That's
on
the
pipeline,
in
our
view,
as
well
as
on
the
stand,
the
vulnerability
details,
page.