►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
B
I
just
started
welcome
to
the
weekly
threat
insights
group
call.
We
have
a
short
agenda,
but
I
think
we'll
end
up
with
some
discussion.
I
hope
just
given
how
our
last
couple
minutes
have
gone.
The
first
question
I
added
to
the
agenda
and
I
think
jonathan
already
answered
it:
asynchronously
we
just
have
a
rename
of
status
and
I
wasn't
sure
if
there
needed
to
be
any
back-end
considerations
for
renaming
like
variables
or
pointers,
or
anything
like
that.
A
Sure
something
it
kind
of
comes
down
to
how
we
want
to
to
handle
this
front
and
back,
but
for
for
one,
if
we
change
it
from
detected
to
nice
triage.
That's
that's
gonna,
be
a
value
that
comes
through
on
the
api,
so
we're
gonna
have
to
go
through
a
a
deprecation
series
on
that
to
make
sure
that
that
catches
all
the
api
changes,
the
second
one
I
mean
we
got-
needs
triage
now
we
may
want
to
change
it
in
the
future.
A
I
think
keeping
just
the
very
base
status
of
detected
is
fine
on
the
back
end
and
then,
if
we
want
to
change
things
on
the
front
end
to
to
reflect,
you
know
changing
how
we
want
to
see
it.
I
think
that's
the
best
way
to
put
it,
so
you
don't
have
to
now
we're
not
constantly
changing
things
on
the
backend.
C
A
A
You
know
I
didn't
even
I
I
meant
to
go
back
and
look
at
the
documentation
on
that
one.
It
is
that
a
constant
value
is
that
is
that
an
enum
value,
or
is
that
a
string
value
that
is
that
comes
through
on
that?
It's.
C
But
I
also
agree
like
the
back
end.
Change
will
be
will
have
lots
of
places
to
touch
because
we
are
also
dependent
on
finding
a
state
on
the
like
the
vulnerability
state.
C
B
B
Any
thoughts
on
maybe
breaking
it
into
two
pieces
they
seem
like
they
could
be
done,
independent
of
each
other,
even
though
it
would
sacrifice
customer
clarity.
D
We
already
have
other
places
where
we
have
two
different
names
for
the
same
thing.
Sometimes
three,
so
I
think
it's
okay
to
at
least
just
temporarily,
make
it
so
that
it
doesn't
match.
A
D
It's
it's
the
whole
application
strategy
that
gets
real
tricky
to
like
switch
over
the
names.
I'm
almost
wondering
if
we
should
just
keep
it
as
detected
on
the
back
end
and
then
just
like
liquid
lindsay
said,
I
don't
know
about
it
at
least
until
we
can
figure
out,
because
it
seems
like
every
few
months.
We
have
something
that
changes
like
the
last
one.
D
We
did
was
renaming
scanner
to
tool,
but
everything
on
the
back
end
is
still
it's
still
using
scanner,
even
though
the
financials
tool,
and
so
like,
would
it
be
better
if
we
waited
until
these
changes
were
more
stable
and
that
we
knew?
We
know
that
this
is
like
the
naming
that
we
want
to
go
forward
with
before
we
do
the
backing
changes,
or
should
we
just
do
it
now?
C
E
Because
because
we
we
have
more
upcoming
changes
there
and
I
I
think
once
once
we
as
you
say,
we're
stable.
We
want
to
go
in
the
backend
all
right
now,
let's
clean
up
and
to
be
honest,
if
if
he
gets
it,
if
he
gets
us
in
the
habit
of
doing
a
little
bit
better
with
the
graphql
documentation,
I
think
I
think
it'll
be
a
a
good,
a
silver
lining
to
this
as
well,
because
because
look
at
this
right,
it
says
vulnerability,
state
and
then
value
confirm
description.
E
Oh
confirmed!
Oh
really,
I
couldn't
tell
it
from
reading
the
fact
it's
just
like
all
the
all
the
documentation
is
like
that.
It's
so
I
think
it
would
be
a
really
good
thing
for
us
to
start
being
a
bit
more
verbose,
a
bit
more,
more
give
a
bit
more
context
to
the
things
that
are
in
the
api
and
it
might
educate
us
to
how
these
things
are
being
used
and-
and
you
know
what
the
directions
we
need
to
go.
B
So,
based
on
this,
it
sounds
like
we
need
some
breakdown
work
on
this
we'd
like
to
have
two
separate
issues:
a
front-end
back-end
issue,
which
we
can
refine
and
prioritize
separately.
We
have
this
one
artifact
that
I
linked
to
here,
which
I
mean
I
kind
of
want
to
just
call
dibs
on
as
a
front-end
issue.
B
Whichever
I
mean,
whoever
wants
to
either
turn
this
into
a
back-end
issue,
and
then
someone
from
the
front-end
team
can
create
the
front
issue
or
vice
versa.
However,
we
want
to
handle
that.
Does
that
sound?
Like
the
agreement,
though,.
C
C
B
B
E
Yeah,
if,
if
we,
if
we
were
to
like
I,
I
like
lindsay's
idea
of
starting
to
keep
track
of
the
the
discrepancies
and
what
I
was
going
to
say
in
terms
of
going
a
step
further
is
just
create
a
epic,
so
we
can
start
putting
putting
all
these
things
around
backhand
inconsistencies
and
if
it
turns
out,
we
close
a
bunch
of
those,
for
whatever
reason
that's
great.
But
if,
if
we're
on
a
point,
we'll
go
hey,
we
got
some
time
we
want
to.
E
E
You
would
take
a
bit
of
commitment
from
from
the
team
to
and
a
bit
of
effort
to.
Remember,
oh
yeah,
we
here's
another
thing
and
always
keep
adding
there.
So
if,
if
the
team
doesn't
think
it's
worth
that
that
trouble
the
overhead,
then
we'll
deal
with
it
later,
it
just
means
somebody
will
have
to
go.
Do
like
a
spike
too.
Okay,
let's
now
find
out
where
all
the
places
where
we've
got
discrepancies.
A
Can
I
throw
another
option
out
there
for
this?
Yes,
please,
rather
than
using
needs
triage,
maybe
identified.
B
For
that
it
was
funny
because
I
think
when
this
first
came
up
it
was
either
this
one
or
the
next
one
it
was
daniel
or
someone
was
like.
Oh
yeah,
that's
easy
I'll!
Just
do
that
right
now
I
was
like
no.
It
stemmed
this
giant.
You
can
see
it
in
this
issue
like
huge
dialogue
around
what
this
should
be
in
the
workflows
around
it,
and
it's
not
something
you
want
to
get
it,
but
if
you
want
to
reach
out
to
matt
and
give
them
your
input
on
that.
B
A
E
I
think
that's
that's
the
idea
and
that's
why
I
posted
that
second
thing:
there,
the
with
the
the
the
follow-up,
because
we
we've
we
so
I
ended
this.
This
awesome
work,
which
is
which
I've
been
wanting
to
see
for
a
while,
which
is
a
a
just,
a
chart
with
the
okay.
Here's
all
our
states
and
here's
how
you
should
use
them
here,
the
possible
transitions-
and
maybe
I
should
just
share
it
so.
E
So
at
least
people
watching
this,
the
the
two
people
watching
this
who
know
what
we're
talking
about
speaking
of
two
people
watching
this
brian
always
watches
it
can
somebody
take
the
is
the.
E
Thank
you
lindsay,
so
this
is.
This
is
what
he
did
and-
and
I
think
it's
great-
I
it
it's
clear
shows
where
you
can
go,
but
we're
here
right
on
the
left
hand,
side
on
detective
versus
nitriage.
So
my
question
there
was:
is
this
issue
separate
from
this
follow-up
work
as
in
we're
putting
neat
triage
on
on
that
page,
but
we're
still
going
to
have
both
at
some
point
or
are
we
jumping
the
gun
a
little
bit
and
just
completely
removing
the
tactic.
B
A
E
Yeah,
well
just
just
to
say
what
my
my
my
suggestion
here
was
that
we
shouldn't
have
a
different
workflow
between
findings
and
vulnerabilities
and
findings,
meaning
things
on
an
all
different
entries
on
a
node
non-default
branch
and
vulnerabilities
entries
on
on
the
default
branch,
because
it's
not
a
it's,
not
a
very
common
use
case.
But
there
are
companies
that
manage
their
vulnerabilities
in
non-default
branches
and
if
we
introduce
a
state,
a
life
cycle
state
different
between
these
two
things.
Now
now
we
break
that
use
case
model.
We
make
it
harder
for
these
users.
A
E
We
we
still
got
something
out
of
this
right,
the
the
the
question
there
is
hey.
If
we
wanted
to
do
the
the
rename
variability
status
detected
to
triage,
we
have
a
way
forward.
Just
change
the
front
end.
Add
some
documentation
to
graphql
to
explain
hey,
you
might
see
this
as
in
these
places
and
that
this
is
what
it
means.
A
I
mean
we
could,
theoretically,
when
we,
when
we
present
the
the
enum
for
detected,
we
can
present
like
kind
of
like
a
rapper
enum
for
needs,
triage,
keep
everything
on
the
back
end
detected
and
just
when
we
present
it
to
the
graphql.
It
just
says
nice
triage
instead
of
detected.
D
I
I
do
like
that
idea
from
just
a
pure
friend
in
perspective,
but
I
do
wonder
if
that
will
break
anybody
who's
using
the
graphql
endpoints
workflow,
because
if
they're
expecting
the
word
detected,
then
that
might
screw
things
up.
A
D
It
would
still
count
as
a
deprecation
right
and
thiago's
mentioned
about.
The
translation
does
open
up
a
can
of
worms.
It's
the
reason
why
a
lot
of
apis
just
use
numbers
and
whatnot,
and
then
you
have
to
map
it
yourself
to
a
name,
but
that's
not
something
that
we
do.
E
I
I
I
don't
think,
there's
anything
wrong
with
that
with
the
using
a
need
numb
with
a
with
a
constant
daniel,
I
like
having
the
detected
confirmed,
resolve
those
names,
but
everybody
using
that
needs
to
know
hey.
This
is
a
constant
and
you
need
to
do
a
mapping
for
translation
is
that
is
that
what
you
mean.
E
D
Yeah,
that's
correct,
so
are
we?
Are
we
talking
about
renaming
the
enum
or
just.
C
Leaving
it
as
detected
so
right
now
what
I
see
in
the
vulnerability
report
page,
we
are
not
using
the
enum
for
displaying
the
in
the
front
end.
We
are
just
hard
coding
it
from
the
constant
file
or
something
so
it
does.
It
have
an
impact
on
like
because
the
enum
change
will
not
change
anything
in
the
front.
C
B
Bring
them
to
be
more
aligned
with
what
they
see
in
the
ui,
but
I
think
it
was
daniel.
That
said,
let
all
these
decisions
settle,
because
we
have
seen
a
high
rate
of
change,
so
it
sounds
to
me
like.
We
still
want
to
have
front
end
issue
that
uses
the
existing
enum
of
detected
but
maps
it
to
a
new
value
of
needs
triage
and
then
somehow,
whether
we
create
a
new
issue
or
if
you
want
to
include
it
in
the
scope
of
this
other
one
track.
B
B
So,
who
wants
to
create
the
back
end
issue,
I'm
going
to
go
ahead
and
say
daniel,
and
I
call
dibs
on
this
big
long,
verbose
issue
for
the
frilly
minor,
front-end
change.
Unless
daniel
you
disagree
and
you
want
something
clean,
we
can
pawn
this
off,
but
no
work
is
better
than
scrolling.
B
A
F
Do
you
want
to
take
it,
I'm
putting
no
I'll
do
it.
E
Is
to
what's
so
so
the
issue
is
to
I'm
writing
down
here
in
the
in
the
agenda,
so
investigate
where
we
need
an
epic
to
collect
all
the
beef.
If
fe
discrepancies.
E
And
let
me
let
me
be
clear
that
is
graphql
description,
discrepancies
and
two
create
at
least
one
issue
to
track
this
discrepancy.
Should
I
just
create
a
spike?
E
E
B
H
B
Thank
you,
jonathan.
Thank
you.
Thank
you.
So
much
daniel
since
you've
been
part
of
this
discussion.
I'm
going
to
go
ahead
and
just
it
should
be
a
really
easy
refinement.
This
is
punishment
for
doing
so
much
refinement
and
having
none
of
them
on
your
plate
right
now,
I'm
going
to
sign
this
little
one
over
to
you
for
an
upcoming
milestone
to
refine
the
front
end
work
for
that
label.
Change.
B
E
No
that'd
be
all
sorry,
there's
a
new
bird
here
on
my
window
and
I've
never
seen
it.
It's
got
a
gorgeous,
yellow
ring
around
its
it's
eye
and
if
I
manage
to
catch
it,
I'll
post
it
on
the
channel,
but
you
guys
can
totally
ignore
me.
E
It's
so
cool
all
right
I
got.
I
did
get
a
a
photo
with
the
monaco
monopoly.