►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group.
A
Welcome
to
the
thread
insights
weekly
group
call:
it's
been
a
while,
since
we've
had
one
of
these,
so
we've
got
some
stuff
on
the
agenda.
Jumping
in
savash
shared
a
demo
he's
been
working
on
the
pipeline
conversion
to
graphql,
so
this
is
kind
of
a
behind
the
scenes
demo.
This
is
happening
in
two
parts,
so
savage
is
working
on
the
vulnerability
report
and
dave
paizak's
been
working
on
the
modal.
A
A
All
right
we've
got
two
issues
for
planning
breakdown,
so
the
first
one
is
around
jira
messaging,
so
jira
issue
creation
messaging.
When
the
issue
is
closed
for
a
git
lab
issue,
we
just
we
doesn't.
We
display
a
closed
indicator
on
the
vulnerability
report
that
equivalent
behavior
should
happen
for
the
jira
issues,
and
my
question
was-
and
I
wasn't
sure
if
anyone
had
a
chance
to
look
at
this
yet
in
advance
is.
Is
there
back-end
work
required
for
this,
or
is
this
a
piece
of
information
we're
already
getting
back
on
the
status
of
the
jira
issues?.
A
C
C
We
don't
have,
it
doesn't
look
like
we
have
the
status
additional
statuses
status,
sign
statuses
for
the
other
states,
and
I
just
saw
that
I
mean
I
hadn't
looked
at
tsubashi's
comment
yet.
B
Yes,
I
think
we
need.
I
agree
with
jonathan.
I
think
we
need
back-end
work
for
this
one
and-
and
I
saw
another
bug
for
deleted
jira
issue
as
well.
It's
kind
of
a
similar
one
because,
like
we
are
not,
there
is
no
communication
with
jira.
If
anything
happens
on
the
jira
side,
so
we
don't
know
whether
the
g
ratio
is
deleted
or
somebody
closed
that
issue,
so
that
mechanism-
I
I
don't
think
it's
present
right
now.
A
Sure
that
those
get
related
as
we're
refining
those
issues.
C
At
the
risk
of
taking
this
off
the
rails
a
little
bit
so
so
I
did
not
see
specifically,
but
I'm
assuming
that
we
we
can
track
the
state
of
the
jira
issues.
Okay,
I
I'm
assuming
that
we
can,
but
I
did
not
explicitly
see
that
anywhere
else
in
the
code.
I
know
that
we
can
link
to
them,
but
I
don't-
I
didn't
see
that
yeah,
so
I
don't
know
how
deep
we
have
to
actually
push
if
it's
just
a
status
that
is
already
available
to
us
through
the
api
awesome.
B
Yeah,
no,
no,
so
the
refinement
me
how
the
did
for
this
issue,
like
the
for
the
deletion,
zero
issue
deletion,
has
the
similar
kind
of
findings
like
there
is
no
communication
from
jira
site.
Maybe
we
need
to
add
something
api
call
or
webhook,
or
something
like
that
and
then
in
on
our
site
for
the
deletion?
It's
I
think
it's
little
bit
easier
than
oh,
we
got.
We
are
like
just
deleting
the
association
and
creating
it
again,
but
for
the
closed,
I
think
we
really
need
to
know
the
status
from
the
genocide.
D
A
D
C
A
The
addition
would
be
in
on
that
display
have
an
indicator
that
it's
closed.
So
when
we
do
the.
C
Retrieval
right
yeah,
so
what
matt
was
saying
about
the
lazy,
the
lazy
loading
like
when
we
pull
up
the
vulnerability
list
like
it?
It
also
it
goes
out
and
actually
checks
the
jira
issue
to
see
if
it's
still
there.
C
C
D
Even
if
we
wanted
to
do
some
sort
of
like
I
know,
we
have
a
lot
of
scheduled
jobs
for
things
like
you
know,
maybe
every
few
hours
or
like
every
24
hours,
we
just
do
kind
of
a
refresh
on
stuff.
I
think
that
would
be
fine
too,
to
do
that
kind
of
an
update.
But
oh,
I
guess
I'm
saying
with
the
assumption
that
this
is
easier
and
a
better
approach
than
just
implementing
the
webhook
callbacks
and
letting
jira
do
its
thing.
It
just
sounds
like
that's
going
to
be.
C
Yeah
I
mean
I,
I
definitely
think
we
need
to
engage
the
ecosystem
team.
You
know,
like
you
said
to
do
that.
I
mean
pulling
all
that
information.
Updating
the
you
know
the
status
of
jira
upon
loading
of
the
vulnerabilities.
C
That
I
mean.
That's
that's
going
to
be
a
big
performance
hit,
so
I
mean
it
feels
like
there
needs
to
be
some
kind
of
service
or
something
running
in
the
background
you
know
like.
C
If
you
look,
if
you
load
a
project
like
like
you,
just
go
to
the
project
page
like
you
know,
pulling
something
like
have
a
service
pulling
that
updating
in
the
background
or
if
there's
like
a
task
that
runs
in
the
background
that
that
does
it
periodically.
I
don't
know,
I
don't
know
how
the
best
way
to
do
it,
but
that's
that
this
seems
like
it
would
be
a
very
time
consuming
process.
Processor,
intensive
task
to
update
all
of
the
jira
statuses.
D
Yeah,
since
we're
we're
still
the
only
place,
I
think
where
we're
actually
reaching
out
and
creating
something
inside
of
jira
as
an
object
and
not
just
pushing
something
pre-existing.
So
I
yeah
we're
a
little
bit
ahead
of
other
parts.
So
I
think
that's
why
I'm
kind
of
a
little
bit
like
I
just
want
to
catch
up
and
see
what
the
ecosystem
team
has
right
now,
because
I
know
there's
a
lot
of
renewed
focus
on
building
out
that
specific
integration.
A
That
wouldn't
make
more
sense
than
to
not
move
forward
with
the
plane,
breakdown
or
refine
into
this
issue,
and
just
start
the
conversation
with
the
ecosystem
team
right
now
about
any
solutions
or
plans.
Or
do
you
think
that
we
need
to
look
at
what
the
back
end
effort
would
be
to
retrieve
the
status?
I
guess
I
just
had
this
blissful
hope
that,
as
we
retrieved,
you
know
a
list
of
issues
that
having
the
status
of
those
issues
wouldn't
be
a
separate
endpoint
call.
D
A
C
A
Can
take
the
action
to
do
that
they
do.
I
know
I
p
ip
is
the
front
end
manager
for
that,
I'm
not
sure
if
he's
full
stack
or
who
the
back-end
manager
would
be,
but
you
know
he
knows
our.
He
knows
us
very
well
lucas
seifert,
so
I
can
take
the
action
for
that.
C
A
So
I
think,
in
addition
to
that,
in
parallel
we
should
still
get
the
back
end
issue
created
and
you
know
continue
with
our
planning
breakdown
and
refinement,
but
also
start
that
discussion.
Do
you
agree.
D
C
A
Okay,
all
right,
thank
you
and
just
to
ensure,
like
I
think,
we've
already
answered
all
these
questions,
but
just
a
reminder.
Our
planning
breakdown
questions
are
the
requirements
clear
enough
to
understand
the
intent
of
the
request.
Does
anyone
have
any
questions
on
the
requirements
for
this
one
dependencies?
I
think
we've
talked
about
that
a
little
bit.
There
might
be
a
dependency
on
the
ecosystem
team,
depending
on
what
we
find
and
then
is
it
small
enough
to
complete
in
one
iteration
if
we
were
to
set
everything
else
aside,.
A
A
I'm
actually
much
bigger
fan
of
that
than
like.
Oh
no,
it's
totally
fine
and
not
knowing,
but
based
on
what
matt's
saying
is
if
it
is,
if
it
does
end
up
being
something
that's
bigger
than
it
would
take
us
to
complete
in
one
milestone.
There's
a
question
of
whether
we'd
actually
go
forward
and
do
it
is
that
right,
matt.
D
Yeah,
I
think
well-
and
I
guess
also
the
thing
is:
let's
say
that
the
ecosystem
is
planning
on
implementing
a
generalized
way
to
handle
webhook
callbacks
from
the
jira
side
and
they're
going
to
do
this
in,
like
two
milestones,
I
would
rather
wait
for
that
group
to
do
that
and
then
leverage
you
know
for
our
purposes,
even
if
it
didn't
like
this
is
not
a
pressing
feature.
I
guess,
like
it's
a
nice
enhancement
to
push
forward,
but
this
isn't
like.
We
have
to
have
it
now.
Okay,.
A
C
Yeah,
I
will
say
real
quick.
One
thing
I
just
thought
about
like
so
one
of
the
issues
is
that
we
cannot
create
another
issue.
If
there,
you
think,
there's
an
issue
out
there
right.
C
Earlier
and
and
let
me
bring
that
up
in
the
chat
yeah.
A
B
C
C
C
C
A
My
gut
was
so
wrong
on
this.
I
thought
getting
the
closed
status
is
going
to
be
much
easier
than
handling
this
recognition
of
something
deleted,
but,
okay,
so
it's
good
to
know.
Thank
you.
Let's
move
on,
we
have
10
more
minutes.
We've
got
one
more
issue
on
here.
This
has
been
on
our
agenda
before
and
there's
been
a
lot
of
discussion
around
it
in
the
issue,
which
is
where
it
should
happen.
My
big
question
for
this
is
based
on
the
discussion.
B
C
A
We
have
another
bug
that
came
up
around.
I
think
it's
related
matt,
the
stuff
that
came
up
yesterday
with
a
customer
who
is
upset
that
I'd
originally
thought
was
a
front-end
bug
and
it
has
to
do
with
the
pipeline
dismissals
and
this
duplication
question
and
I'm
wondering
if
this
deserves
its
own
discussion
like
it's.
C
Actually
putting
my
comment
in
there
now
on
the
actual
discussion,
I
I
don't
think
we're
gonna
figure
this
out
in
this
setting
now.
A
C
I
I
feel
like
this
is,
I
feel
like
this
is
still
an
issue
where
it's
closed,
like
resolved,
resolves
in
on
one
issue,
but
the
other
one
is
still
going
if
it's
a
different
scanner-
and
I
believe
that
was
the
issue
that
there's
two
different
scanners
reporting
the
same
issue
or
the
same
vulnerability
and
one
of
them
said
resolve
the
other
one.
It
said
still
open,
because
that's
what
dominic
was
saying
because
he
manually
closed,
he
manually
had
closed
it.
C
So
I'm
just
putting
my
comment
in
there
yeah.
So
I
don't
have
a
result
right
now,.
A
A
Off
okay,
so
how
do
we
want
to
move
forward
with
this?
Because
again,
this
is
in
14-0,
we're
not
going
to
resolve
it
here.
There's
some
discussion:
do
we
want
to
do
this
asynchronously
in
the
issue,
or
do
we
think
we
need
to
schedule
a
separate
discussion
around
this
with
a
broader
audience
at
all,.
A
Okay,
I
might
delegate
that
one
to
tiago
but
we'll
take
that
as
the
action
from
this
discussion
regarding
this
issue.
So
I
think,
unless,
if
you
guys
have
anything
else
or
want
to
talk
about
this
one
further,
I
think
that's
the
end
of
our
agenda.
D
D
Is
it
the
location
like
jonathan
my
my
original
take
on
this
was
in
theory,
two
different
scanners
could
have
this
happen
and
have
that
collision,
but
just
by
the
nature
of
how
the
scanners
report
things
so
differently,
it's
very
unlikely,
so
it
seems
like
possible,
but
not
plausible,
which
is
why
we're
seeing
it
same
scanner
and
then
yeah.
I
don't
know
how
the
uu
id
thing
factors
in
or
not.
I.
C
Mean
yeah
I
mean
the
original
problem
was
we
mark
vulnerabilities
resolved?
We
detect
duplicate
vulnerability.
A
duplicate
vulnerability
only
refers
to
the
case
when
two
different
analyzers
detect
a
finding
with
the
same
location
and
analyzer
and
same
location
and
identifier
with
two
different
analyzers.
So
that
is
that's
the
problem
on
this
one.
C
Yeah,
I
I
I
remember
one
of
the
converse,
and
I
said
I
didn't
want
to
talk
about
this
one
anymore,
but
I
I
remember
the
like
we
talked
about.
You
know
if
there
are
two
different
scanners,
if
they,
if
they're
looking
at
the
gitlab
scanner
versus
you,
know
a
third-party
scanner
and
they
see
one
has
this
list
of
vulnerabilities.
D
Well-
and
I
think,
one
of
the
other
cases-
it's
probably
more
likely
for
some
of
the
static
analysis
tools,
because
I
think
what
I
always
have
to
remind
myself
and
get
confused
this
analyzer
is
the
individual
engine.
You
can
have
multiple
analyzers
inside
of
one
scanner,
so
I
think
in
theory,
if
you
ran
multiple
static
analysis,
analyzers
or
even
like
secret
detection,
some
of
the
sas
analyzers
will
also
do
some
form
of
secret
detection
yeah.
I
think
that's
where
you're
going
to
see
those
collisions
but
yeah
like
dast,
pointing
at
something
like
a
sas
finding.