►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
Welcome
to
the
weekly
threat
insights
group
call
jumping
right
into
the
agenda.
We've
got
some
accomplishments
to
highlight.
You
can
see
the
four
items
from
this
just
this
last
week.
This
was
one
week
time
range
yay
team
and
I'm
not
sure
who
added
the
previous
discussion.
So
who
wants
to
pretend
like
they're
mark
right
now.
A
B
Let
me
just
let
me
get
my
best
mark
impression
going
on
yo.
It's
me
it's
mark,
oh
my
god,
so
sound
like
a
ghost
okay,
well,
anyways
mark
had
some
concerns
about
some
other
things
that
they're
doing
on
the
other
secure
team
and
we,
but
I
responded.
C
D
B
By
some
back
and
work
anyways,
he
agreed
to
that
and
now
is
like
oh
you're
blocking
us.
So
do
the
one
thing
and
I
am,
and
so
hopefully
I'll
have
an
mr
up
today
it
gets
merged
sometime
and
unblocks
them
in
the
future.
A
Both
a
great
imitation
of
mark-
and
you
have
just
wrapped
the
whole
explanation
up
to
completion,
so
they
had,
if
I
understood
correctly,
they
had
some
dependencies
and
some
of
the
early
stages
of
this,
mr
widget
refactor
we've
taken
on
those
early,
so
we
believe
we've
unblocked
the
work
that
secure
team
wants
to
do
and
we
can
continue
to
re-prioritize
the
other
steps
of
that.
Mr
widget.
How
matt
fails
his
best
fit.
B
Yeah
and
the
other,
the
so
okay,
so
going
into
details
a
little
bit
more.
This
is
for
the.
B
B
A
B
Very
cool
anything
new
demo,
I
think,
oh,
I
think
the
the
failed
pipeline
badge
got
merged
in
so.
D
B
Great
that
will
up
that
will
bring
the
vulnerability
report
pipeline
status
to
completion.
I
don't
think
it's
I
think
it's
the
staging
now,
maybe
in
production.
That
is
one
thing
to
demo.
That's
that's
it
actually.
That's
all.
I
can
think
of
moving
on
to
playing
breakdown,
create
a
jira
issue
for
vulnerability.
B
So
matt
says
people
want
this
for
some
reason,
not
sure
I
believe
him,
but
it
seems
like
it
seems
like
an
okay
thing.
Matt.
C
Yeah
sure
I
I
will
I'll
not
say
the
specific
numbers
since
we're
recording
this.
You
can
see
to
the
document,
but
I
just
want
to
point
out
like
if
ever
there
were
a
feature
that
had
some
initial
interest
and
then
had
additional
folks
from
the
sales
team
keep
lumping
on
like
hey.
I
have
another
customer
prospect
who
wants
this
and
oh
look.
I
also
have
one
the
demand
for
this
is
really
really
high,
which
is
why
I
moved
the
integration
work
from.
C
D
C
Yeah,
so
the
intentions
to
do
it
as
soon
as
possible,
just
because
of
the
clear
market
demand
for
this.
So
what
is
interesting
is
while
we
do
have
an
existing
gear
integration.
As
alan
points
out
further
down,
the
integration
is
more
of
a
window
into
a
jira
ex
project.
C
It
doesn't
really
have
a
whole
lot
of
link
between
the
two
projects,
the
use
case
of
having
vulnerabilities
specifically
handled
and
managed
inside
of
gitlab
people
really
like
that,
but
they
do
all
of
the
assigning
of
work
product
to
their
engineering
teams
in
jira
they
do
their
planning
boards
there.
That's
where
the
scrum
masters
organize
things,
so
they
need
to
get
the
vulnerability
information
from
the
get
lab
into
jira
for
the
scheduling.
So
having
that
direct
push
is
a
huge
efficiency
win
for
these
folks.
D
So
he
provided
a
initial
breakdown.
His
suggestion
is
that
we
have
one
epic
for
the
configuration
for
vulnerability,
the
gear
integration,
configuration
ability
and
a
second
epic
for
issue
creation.
So
on
that
first
one
there,
he
breaks
it
down
a
little
bit
further,
I'm
not
going
to
read
in
detail.
C
C
The
rethinking
of
that
was,
if
we
do
it,
as
he's
suggesting
I'm
wondering
if
there's
no
validation
at
all
on
the
issue
type
in
that
your
project.
So
if
we
don't
do
any
sort
of
validation,
that's
just
pushing
any
failure
state
to
when
the
user
first
tries
to
use
the
feature
from
a
vulnerability,
so
they're
going
to
go
and
hit,
create
and
they're
going
to
get
back
some
response
which
assume
we
or
presumably
there's
an
error
and
we'll
have
to
display
something.
C
So
if
we
were
to
instead
try
to
validate
at
the
time
that
you're
configuring
the
integration
this
is,
I
think,
alexander
and
I
were
kind
of
going
back
and
forth
in
the
issue
design
about
this.
Well,
you
would
still
have
to
make
the
api
call
out
to
the
jira
instance
to
validate
that
that
field
exists.
Well,
that
call
is
actually
the
same
method.
D
I
I
don't
know
it's
it's
a
it's
a
good
point.
I
I
I
think
if
it
doesn't
add
much
it's
worthwhile
doing
it
as
the
first
iteration,
but
they're
definitely
levels
to
this
as
well.
So
if
we
do
that,
there's
also
a
situation
where
people
could
change
the
jira
issue,
types
of
workflow
right,
the
schema
there
and
then
suddenly
what
worked
when
we
when
we
first
configured,
doesn't
work
anymore.
C
Right
you
could,
we
would
still
have
to
have
that
when
you
tried
to
create
the
issue.
Yes
try
to
account
for
that
in
the
design,
with
the
new
drop
down
of.
If
you
change
something
in
the
integration,
it
basically
clears
out
your
project
selection
and
then
there's
a
little
refresh
button
to
basically
say:
hey,
go,
go
fetch
the
new
thing
and
come
back
but
yeah.
Certainly
if
this
is
too
much
scope
for
it,
we
can
go
with
the
text.
Input
field
it
just.
C
B
This
is
sort
of
getting
into
refinement,
but
I
would
really
like
the
first
sort
of
ticket
to
be
like
investigate
that
and
be
like
does
the
drop?
Can
we
get
the
drop
down
with
like
minimal
effort?
I
don't
know
what
the
jira
api
is
like
or
how
that's
really
handled
in
our
application.
So
I
have
to
dig
into
it
but
like
if
it
is
a
minor
amount
of
extra
work.
I'd
say
just
go
for
the
drop
down,
but
if
it
turns
into
a
thing,
then
input
box.
D
D
C
C
But
I
can
still
create
an
issue
in
that
project
to
get
lab
issue
so
from
vulnerabilities.
You
can
still
just
sit
there
and
hit
create
issue
all
day
long
and
you
get
these
gitlab
issues
with
this
work.
We
decided
that
if
you
enable
this
part
of
the
functionality
is,
it
will
disable
creating
a
gitlab
issue
from
a
vulnerability.
This
makes
it
an
either
or
right,
because
I'm
overriding
that
behavior
in
the
integration
setting
and
that's
where
I
want
the
issues
to
go.
C
B
On
just
just
make
sure
I
understood
it
works,
you
can
still
create
an
issue
from
the
pipeline
view,
but
it
is
it's
a
gitlab
issue,
not
a
jira
issue,
wow
yeah.
We
should
disable
that
yeah.
A
C
No
so
today
that
is
the
problem.
Is
people
are
under
the
impression
that
our
jira
integration
actually
creates
issues
in
jira
from
the
get
lab
side,
not
just
for
vulnerability
management
but
like
period
end
of
sentence?
So
you
know,
if
you're
on
a
project,
you
can
go
up
to
the
top
menu
and
there's
the
little
like
plus,
and
you
can
say,
create
a
new
issue,
a
new
epic
or
whatever.
C
C
C
I
think
it's
more
apparent,
because
teams
are
not
using
git
lab
issues
as
part
of
the
regular
workflow,
but
since
they
are
using
our
scm
and
our
pipelines,
they
are
seeing
the
vulnerability
management
side
and
the
dashboards
and
they're
going
oh
cool,
create
issue.
Let
me
hit
that
button
and
then
it
makes
a
gitlab
issue
and
they're
like.
Why
isn't
this
in
jira
I
configured
the
integration.
C
It
doesn't
work
that
way.
Yet
so
that's
what
we're
fixing!
So
that's
why
I'm
saying
if
we
do
it
for
just
the
standalone
vulnerability
details
pages,
we
either
should
do
it
in
the
pipeline
in
the
mr
at
the
same
time,
or
if
that's
too
much,
then
let's
just
hide
the
behavior
when
the
integration
is
on
for
now,
so
that
it's
not
like
you're
getting
two
different
issues
and
types
in
two
different.
B
Places
those
people
should
just
convert
from
jira.
I
think
gitlab
has
a
product
similar.
C
C
That's
still
a
lot
of
value
for
them.
If
they
can
have
that
that
integration
point
with
us
like
to
be
clear,
we're
doing
this
as
the
first
part
of
anywhere
in
git
lab
doing
a
deeper
juror
integration,
which
is
pretty
awesome.
So
I've
already
had
inquiries
from
the
group
that
owns
this
and
other
places
to
like
hey.
Could
you
guys
do
this
in
a
way
that
we
could
copy
it
later
for
other
object,
types
and
sync
those
to
jira?
Because
that's
that's
pretty
cool
and
people
want
it.
C
A
Excellent
we're
happy
to
go
and
attend
whatever
their
discussion.
Q,
a
open
office
hour
sessions
are
or,
however,
we
need
to
help
facilitate
that.
C
Yeah-
and
I
don't
know
how
actively
this
plug-in
is
being
worked
on
or
when
the
last
time
it
was
really
touched,
so
this
could
be
kind
of
picking
up
some
a
little
bit
of
stale
knowledge
here.
I've
also
been
cautioned
not
to
scare
you
alexander,
but
that
this
is
a
it's
an
old
piece
of
code.
It
is
fairly
brittle
you'll
see
that
the
way
that
the
designs
are
laid
out,
it's
a
little
bit
kind
of
like
we
shoved
our
piece
in
the
middle
of
the
larger
integration.
A
Which
is
a
really
good
call
out
matt
that
we
will
be
contributing
to
this
other
stage
of
the
product
as
part
of
this
change,
we're
not
dependent
on
them,
making
a
change,
there's
nothing
that
we're
going
to
be
harnessing
that's
already.
There
there'll
be
new
code
added
to
another
part
of
the
code
that
we've
never
worked
in.
B
Got
it
thank
you
I'll,
be
sure
to
factor
in
the
time
it'll
take
the
refactor
into
the
refinement.
D
I
I
agree
with
this
point:
there
just
doing
the
minimum
amount
of
work
necessary,
but
with
required
fields,
especially
relying
on
default
jira
scheme
scheme
map
schemes,
because
you
know
it
can
get
as
complex
as
you
want,
but
but
I
had
a
follow-up
piggyback
on
that
which
is
do
we?
Are
we
expected
to
handle
two-way
sync?
As
an
area
where
you
know
we
create
a
an
issue
from
vulnerability
in
gitlab
and
then,
when
that
issue
is
closed
in
jira,
do
we
update
the
probability
gitlab.
C
Great
question,
so
let
me
answer
just
to
alan's
question
first,
so
we
are
very
purposely
using
only
the
title,
the
description
fields,
which
I
don't
think
that's
actually
what
jira
calls
them,
but
those
are
the
only
two
I
think
required
and
guaranteed
field
types
for
all
their
default,
as
well
as
custom
objects.
It
has
to
have
a
title
and
it
has
to
have
a
description.
C
So
that's
why
we're
putting
our
title
in
their
title
and
then
everything
else
is
just
getting
dumped
in
the
description,
so
we
don't
need
to
worry
about
anything
fancier
and
then
tiago
to
your
question.
No,
this
is
not
a
two-way
sync.
This
is
basically
a
one-way
push
of
information
from
us
over
onto
the
jira
side.
C
C
D
D
E
C
C
F
Would
recommend
against
that?
Just
for
the
reason
is
that
they're
two
different
products
at
atlassian
and
most
customers
are
on
the
cloud
hosting
for
excellent,
but
definitely
a
great
question,
though
it's
unlike
gitlab,
where
we
have
a
big
mixture
of
self-hosted
and
cloud-hosted
they're,
primarily
cloud
listed.
F
F
F
So
what
should
we
do
to
accelerate
this
as
appropriate
due
to
the
priority
and
impact
lower
priority?
Other
things
add
people
from
other
teams
temporarily,
etc.
C
I
I
mean
I
don't
see
a
real
need
to
move
or
I
should
say,
to
accelerate,
I
think,
keeping
it
where
it
is,
I'm
okay
with
that
right
now
and
then
yeah,
a
big
part
of
that
was
well,
not
a
big
part.
A
a
good
coincidence
of
coincidence
of
timing
is
the
mr
security
report,
the
other
three
steps
moving
that
priority
out.
So
if
this
were
to
even
start
with.
C
C
Yeah,
I
think
if
we
start
doing
some
of
the
technical
investigation
work
in
13-6,
and
even
I
don't
know
if
we
even
get
started
or
not,
but
try
to
work
on
this
in
13-7-
that's
very
much
in
line
where
I
would
want
to
keep
it,
because
this
got
pulled
in
from
like
probably
middle
of
next
year
or
later
I
do
want
to
go
back
wayne.
You
made
a
great
point.
C
So
the
way
that
I
had
asked
for
this
in
the
issue
was
to
actually
support,
so
we
do
support
integrations
with
both
the
jira
on-prem
as
well
as
cloud.
We
have
two
different
plug-ins.
I
asked
for
both
because
I
honestly
don't
have
a
good
sense
of
what
the
breakdown
is
among
the
customers
that
have
asked
for
this.
C
C
Yeah
exactly
I
have
a
bunch
of
salesforce
links
and
I
would
have
to
go
shake
a
lot
of
trees
to
figure
that
out.
I
can
try
to
get
an
answer
on
that
to
give
a
better
sense
of
that
gideop,
but
yeah
we
do
have
plug-ins
for
both
places.
So
I
think
it's
in
lieu
of
a
a
quick
answer.
The
decision
could
be.
We
can
do
cloud
first
and
call
that
the
mvc
and
then
look
at
if
it
even
makes
sense
to
do
the
self-managed
portion
and.
D
Are
you
going
to
work
out
an
instance
for
us
as
well
matt
because
it
because
not
only
we
need
it
for
development,
but
I'm
thinking
of
automated
testing
as
well
integration
testing.
So
we
need
something
that's
alive
there,
but
we
haven't
decided
and
lindsay.
I
saw
you
mentioned
that
you're
gonna
mention,
which
is
great,
because
we
need
to
decide
how
we're
gonna
keep
testing
this.
C
Yeah
and
months
back
when
I
I
had
poked
at
something
else
related
to
this,
I
feel,
like
somebody
internally
had
pointed
me,
towards
a
jira
instance
that
was
used
in
some
projects
for
some
testing.
Let
me
go
see
if
I
can
dig
that
up
as
well,
so
we
must
have
these
in
some
places.
It
doesn't
seem
very
clear.
D
We'll
probably
need
we'll
probably
need
multiple
instances.
I'm
guessing
there
will
be
a
dedicated
instance
for
for
automation,
tests
a
dedicated
if
a
developer
wants
to
do
something
locally,
they'll
need
one
so
or
maybe
that
that
one
is
the
one
that
can
be
shared.
I
just
don't
know
how
well
this
will
play.
If
you
know
jonathan
is
doing
some
tests
there
and
then
alexander
decides
to
use
the
same
instance
to
do
yeah.
D
A
This
feels
like
a
tricky
one
from
a
testing
perspective
and
that
we
should
have
will
come
to
this
meeting
next
week,
since
it's
the
maya
friendly
time
and
he's
in
dublin
to
talk
specifically
about
the
testing
fitness
and
the
things
you
guys
are
just
bringing
up
I'll.
Add
that
to
that
mention
in
the
design
issue
or
epic,
whichever
one
makes
more
sense.
A
A
A
D
A
D
Yeah
write
some
spikes
on
that
configuration
epic
because
we'll
need
them
anyway.
So
we'll
start.
A
B
Yeah
and
then,
like
you
know,
as
alan
has
mentioned
as
well
like
there
can
be
a
ticket.
That's
like
a
spike
on
investigating
your
connection
and
that
could
probably
get
start
working
on
like
asap.