►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group.
A
A
Oh
okay,
we've
got
a
few
items
for
planning
breakdown,
I'll
talk,
I'll
verbalize,
the
first
one,
because
I
added
it
so
we
we
brought
this
to
last
week's
meeting.
Oh
there
he
is,
I
was
gonna
say
this
came
up
in
last
week's
meeting,
but
matt
wasn't
there
to
answer
questions
so
we
kind
of
deferred
it
for
this
week.
So
this
issue
is
all
about
auto,
resolving
vulnerabilities
that
are
no
longer
found
in
subsequent
scans.
A
B
I
think
the
the
question
we
were
discussing
in
the
last
meeting
was
like
what
will
happen
after
auto
reserve
with
the
issue
links
and
should
we
close
those
issue
links
or
should
we
communicate
somehow,
and
I
think
there
is
a
com
I
was
reading
in
the
morning
as
well
like
there
is
a
comment
from
andy
like
it.
It
will
come
into
the
second
iteration
or
something,
and
but
it
needs
to
be
decided.
If
not
it's
not
decided
yet.
So
it's
it's
kind
of
an
open
things.
We
need
to
discuss.
C
I
almost
feel
like
it's
something
that
we
should
consider
making
a
setting.
I
know
because
then
it
kind
of
opens
up
the
question
of
if
I've
created
the
issue
from
the
vulnerability,
that's
pretty
clear,
but
what?
If
I've
related
issues
to
the
vulnerability
and
link
things
together?
And
I
know
our
linking
is
a
little
bit
looser
than
like
the
mrs
issues.
C
A
C
And
if
we
decide
that
it's
worth
adding
that
as
an
additional
behavior
or
you
know
a
setting
if
we
get
addressed
in
the
future
but
for
now
yeah-
let's,
let's
just
leave
it
like.
If
you
were
to
resolve
an
vulnerability
today,
it
doesn't
do
anything
to
the
issues,
it
leaves
the
links
and
it
leaves
them
at
whatever
state
they're
in.
So
I
think
the
auto
resolve
will
just
do
the
same
thing.
D
D
E
Well,
this
is
a
great
idea,
but
I
don't
think
we
have
the
technical
infrastructure
to
do
this.
I
mean
if
we
had
the
state
transition
mechanism,
we
could
create
a
note
saying
that,
hey
that
the
vulnerability
has
transitioned
to
a
result,
state
or
a
dismissed
state.
Would
you
like
to
close
this
issue?
Yes,
no
or
whatever,
but
now
I
don't
think
we
have
the
technical
capacity
to
like
detect.
D
E
Yeah
going
back
to
the
automatically
resolving
of
the
vulnerabilities,
I
am
not
sure
this
is.
This
is
an
open
question,
because
I
think
lucas,
charles
and
and
ross,
I
think,
did
some
work
in
the
fingerprinting
department,
so
they
they,
they
were
trying
to
do
some
additional
algorithms
to
determine
whether
the
vulnerability
is
not
present
in
the
subsequent
scans,
which
would
allow
us
to
get
better
results.
Because
if
you
record,
if
I
recall
correctly-
we've
been
getting
some
false
positives
in
that
department.
E
E
E
It
was
fingerprinting
the
vulnerability
findings
with
priorities,
so
you
could
like
have
different
algorithms
to
fingerprint
the
vulnerability
finding
and
it
would
try
to
match
them
according
to
the
highest
priority
algorithm
and
the
rest
of
them
to
see.
If
that's
the
same
vulnerability,
but
it
was,
it
turned
out
that
we
had
to
disable
it
because
it
was
far
too
complex
and
it
took
far
too
much
time
to
process
any
kind
of
report.
We
had
very
high
pressure
on
the
store
report
service
and
we
had
to
put
it
behind
the
future
flag.
E
A
C
Mijo
is
it
any
worse
than
today,
where
I
mean
the
problem
is
let's
say
that
I
have
a
static
analysis
passed
and
it
finds
you
know
50
things,
and
somebody
goes
in
and
moves
a
couple
lines
of
code
around
today.
I
would
end
up
with
50
things
that
are
already
in
my
vulnerability
report
that
may
show
up
as
no
longer
detected,
but
then
I
get
50
new
ones
in
the
feature
branch.
C
E
Well
now
the
point,
the
point:
your
eyes
is
violet
the
question
I
the
question
I
would
answer
with
is
like:
do
we
have
a
bigger
priority
on
accuracy
or
do
we
have
bigger
priority
on
getting
having
the
future
be
easily
adopted
because
automatically
closing
it
as
you
describe
and
with
low
accuracy
as
we
currently
have,
it
is
going
to
basically
have
people
end
up
with
hundreds
of
automatically
close
vulnerabilities
which
might
ease
the
adoption
part,
but
we
are
going
to
get
questions
so.
Can
you
improve
the
accuracy
now.
C
Well,
I
think
we're
actually
kind
of
in
the
reverse
spot
of
what
you
say
is
that
people
already
don't
like
the
accuracy
of
the
fingerprinting
and
that's
a
known
problem
and
they're
kind
of
going?
Can't
you
please
close
these
automatically
have
hundreds
or
thousands
of
them.
So
even
once
we
do
improve
the
accuracy
there's
still.
This
seems
to
be
a
philosophical
difference
between
teams
that
want
to
review
everything
and
teams.
That
say,
you
know
what
I
trust
the
scanners.
If
this
camera
says
it's
not
there,
I
want
to
close
it
out.
C
Also
the
developer
fixed
it,
or
maybe
we
applied
a
patch
upgraded,
a
module
whatever
it
is.
I
don't
want
to
spend
people
time
looking
at
stuff
that
has
gone
away,
so
I
think
it
solves
a
very
immediate
need
and
then,
while
the
scanner
teams
improve
the
fingerprinting
accuracy,
the
feature
still
has
the
same
amount
of
benefit
going
forward.
D
E
E
A
A
F
Yeah,
I
just
had
a
look.
It
looks
pretty
straightforward.
I
think
we
will
run
into
some
issues
with
testing
this,
because
it's
one
of
those
things
where
it
requires
a
pretty
specific
setup
before
you
can.
You
can
test
it.
Then
after
you
run
the
test,
you
have
to
basically
repeat
the
process
again
to
get
back
to
the
testable
state,
but
just
from
like
an
implementation
perspective,
it
looks
fairly
straightforward.
B
C
Yeah
so
things
like
the
automatic
closing
of
the
issues.
These
are
things
that
we
can
worry
about
later.
I
would
keep
just
what
we've
got
scope
for
right
now:
okay
and
I
to
be
honest,
I
suspect
that
in
a
very
large
percentage
of
cases,
teams
that
are
going
to
want
to
use
the
auto
opt-in
feature,
it's
probably
for
a
lot
of
the
vulnerabilities
that
are
not
getting
automatically
fixed
and
closed.
A
A
A
A
F
A
Okay:
let's
talk
about
ways
that
we
can
break
this
down
a
little
further
than
and
have
whether
it's
two
mvcs
or
an
iterative
approach.
Any
thoughts
on
that.
D
On
the
back
end,
though,
but
sorry
just
say
what
I
was
gonna
say
before,
I
don't
believe:
does
it
simpler,
mvc,
so
matt
hasn't
said
anything
I'm
thinking
this
is
as
simple
as
it
gets?
D
Is
there
anything
else
in
the
back
end
or
sh
that
we
want
to
discuss,
or
should
we
take
this
asynchronously
and
and
asana
dri
to
go
and
answer
the
the
the
planning
breakdown
like
the
proposed
proposed
implementation
issues?
A
We
are
I'm
sorry.
I
was
still
trying
to
understand
mihao's
suggestion,
so
what
I
heard
was
that
we
weren't
ready
to
go
forward
with
the
creation
of
the
implementation
issues,
because
this
is
large
and
if
there's
a
way
that
we
can
break
it
down
into
smaller
pieces,
because
this
is
the
way
we've
defined,
how
we
graduate
from
the
planning
breakdown
discussion
to
the
next
step
of
creating
implementation
issues.
A
E
I
I'm
basically
saying
that
we
should
like
do
the
very,
very
minimal
approach
to
this
and
enable
it
for
just
in
back
end
aft
under
a
feature
flag
and
see
how
that
behaves
see.
If
that
solves
some
of
our
problems,
and
then
we
can
iterate
on
that.
A
I
think
it
makes
a
lot
of
sense.
I've
heard
some
feedback
recently
that,
when
back-end
apis
get
created
way
in
advance,
there's
been
times
where
the
front
end
doesn't
necessarily
either
have
exactly
what
they
need
or
understand
it
entirely.
So
if
we
do
take
that
approach,
I
think
it'd
be
great
to
have
a
front-end
dri
who
gets
early
review
and
input
on
the
api
that
gets
created
as
part
of
this
phase.
D
D
A
A
A
So,
given
that
and
this,
it
is
sort
of
sort
of
maybe
get
your
your
toes
wet
or
their
ease
into
this
a
little
bit.
Do
we
feel
like
we
should
move
this
out
of
planning.
I
don't
want
to
say
out
of
planning
breakdown
and
then
to
refine
it.
They've
kind
of
got
this
weird
limbo
in
between,
like
we've,
had
the
planning
breakdown
discussion
and
we're
creating
the
implementation
issues
before
they
get
refined
we're
fine.
Are
we
ready
to
move
this
to
the
implementation
issue?
Creation
portion
of
planning
breakdown.
A
Excellent,
so
thiago
do
we
want
to
nominate
dris
for
this?
Do
you
want
to
ask
for
volunteers.
D
I
was
going
to
bring
up
what
what
I
had
in
3a
1,
just
to
say
that
there's
a
few
things
still
ahead
of
this.
So
I
don't
know
if
it's
too
early
to
pick
the
rise
or
if
we
can
pick
them
asynchronously,
and
I
don't.
I
don't-
expect
anyone
to
to
write
implementation
issues.
This
milestone
matt.
What
was
your
expectation
as
as
the
as
the
priority
tsar.
C
D
So
I'll
I'll
pick
I'll
pick
back
a
backhand
dri
in
the
coming
week,
or
so
I'm
saying
this
because
I
know
mihao
is
a
half
capacity.
This
milestone
he's
away
the
next
milestone
and
then
to
be
decided
whether
or
not
he
he
returns
and
yeah.
I
need
to
take
that
into
consideration.
Picking
picking
who
goes
in
there.
A
Okay,
we'll
do
the
same
with
the
front-end
dri
as
well.
It
just
dawned
on
me
that
we
shouldn't
have
started
with
this
topic.
We
should
have
started
with
topic
b
that
thiago
added,
because
it's
actually
an
item
that
is
in
14
1..
So
this
is
what
happens
when
I
don't
look
down
the
list
of
the
agenda
before
we
just
jump
right
in.
C
D
D
C
Yeah
I
was
kind
of
halfway
through
my
response
and
the
issue
on
that
one.
I
I
kind
of
like
more
having
sort
of
the
added
via
api,
or
something
like
that.
I
guess
I
have
less
strong
feelings
about
what
we
call
the
scan
type
in
the
scanner
name,
just
that
I
want
to
be
able
to
make
sure
we
can
distinguish
something
that
was
created
purely
via
api
versus
in
that
form
at
a
later
date.
E
D
C
E
I'm
afraid
not
I
I
mean
the
scanner
is
a
different
entity
altogether.
So
I'd
rather
not
stick
detection
method
there,
because
I'm
going
to
get
many
questions
asked
by
reverse.
Why
are
we
sticking
this
thing
where
it
doesn't
obviously
belong
to
so
well,
my
proposition
was
to
add
the
scanner
type
hover
and
scanner
name
manually
added.
We
added
the
api.
So
if
someone
decides
to
change
that
is
their
own
problem.
But
if
someone
uses
the
api,
then
they
should
be
able.
We
should
be
able
to
filter
out
those
vulnerabilities
later
on.
C
E
Yeah,
the
additional
point
I
wanted
to
rise
here
is
that
we
should
have
the
scanner
type
manual,
because
I
think
this
is
a
perfectly
perfectly
valid
value
for
a
scanner
type.
I
mean.
Sometimes
people
manually
find
full
vulnerabilities,
and
this
is
a
this
sometimes
happens,
and
this
should
be
an
option
there.
So
that's
that's
that's
why
I
kind
of
didn't
agree
with
the
manual
scanner
type.
D
F
D
I
was
to
say,
and
in
reading
trying
to
understand
the
model,
you
know:
there's
scanner,
type,
report,
type
scanner,
name
and
now
detection
method.
I
think
daniel.
You
answered
my
question
in
an
issuer
or
slack
that
the
drop
down
you
you
and
I
as
well
lindsay
the
drop
down
on
the
ui,
the
filter
that
has
its
own
in
in
the
front
end.
So
if
we
do
add
this
kind
of
type
order
in
the
back
end,
do
we
want
that
added
to
the
front
end
as
well.
E
E
A
C
E
F
Yeah,
I
don't,
I
don't
recall
there
being
a
design
to
pick
the
scanner
type.
D
F
B
E
Did
I
just
break
the
meeting?
I
just
I
just
realized
that
when
tiago
started
talking
about
the
scanner
type,
I
realized
he's
talking
about
the
vulnerability
list.
When
you
can
filter
those,
and
then
I
realize
that
what
we
are
essentially
adding
now
is
detection
method,
which
would
be
an
and
different
filter.
E
Which
kind
of
makes
it
hard?
Because
if
we
right
now,
if
we
add
a
scanner
type
of
hover
or
manual
or
whatever,
we
will
expose
it
in
user
interface,
but
we
don't
have
the
ability
to
filter
two
scanner
names,
if
I
recall
correctly
so
you're
going.
If
you,
if
you
have
any
vulnerabilities
that
have
been
created
with
a
scanner
type
of
over
but
were
not
created
by
the
api,
but
something
else,
then
they
are
going
to
show
their
app
as
well.
D
A
I've
been
watching
watching
daniel's
reaction
to
this,
because
I
think
he
might
know
how
this
is
going
to
work
and
my
how
this
might
play
out
and
have
some
warnings
to
heed
around
this.
But
if
there's
a
way
that
we
can
find
a
solution
that
doesn't
overload
the
scanner
filter
anymore,
I
think
that
would
be.
A
We
don't,
we
only
have
one
minute
left,
so
we're
gonna
have
to
save
that
for
next
week.
As
far
as
the
kickoff
goes,
I
think,
if
thiago
can,
I
can
just
share
very
helpful
posts
and
slack-
or
you
know,
record
a
very
small
video
him,
and
I
can
conspire
on
that
later
and
we'll
find
an
async
way
to
cover
that
we
need
to
do
the
same
thing
for
container
security,
because
that
call
got
canceled
today.