►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
B
Yeah
I
cheated,
I
had
it
as
read
only
but
stuck
it
in
this
actually,
so
it
came
out
of
a
conversation
I
was
having
this
morning
with
cindy
blake,
our
product,
marketing
manager
and
kind
of
a
broader
discussion
around
how
we
talk
externally
about
our
security
tools
and
one
of
the
challenges
is
a
lot
of
people.
Don't
know
that
get
lab
has
what
is
quickly
becoming
sort
of
like
best
in
class
in
a
lot
of
ways,
and
the
analysts
look
very
favorably
what
we're
doing
and
she
made
a
really
good
point.
B
Vulnerability
management
is
maybe
not
a
term
that
resonates
with
engineers
that
are
not
like
security,
focused
necessarily
like
on
a
security
team,
but
that's
how
we
talk
about
like
the
mr
security
widget
and
all
of
these
sort
of
shifted
left
scanning
stuff.
So
her
thinking
was
maybe
we
need
a
better
name
for
that,
and
potentially
talk
about
this
messaging
a
little
bit
differently
to
kind
of
say
the
reverse
too.
If
you
didn't
know
that
the
mr
security
widget
was
part
of
vulnerability
management,
it
makes
it
more
difficult
to
find
in
the
documentation.
B
If
somebody,
if
you
were
looking
at
all
these
scanning
tools
and
had
this
way
to
see,
potentially,
you
know
caught
vulnerabilities
in
your
workflow
like
what
would
you
call
that
we
don't
have
to
do
this
interactively?
It
was
just
more.
I
kind
of
wanted
to
explain
it.
So
if
you
have
any
thoughts
or
suggestions,
just
kind
of
trying
to
crowdsource
some
ideas
and
and
maybe
we'll
end
up
doing
something
with
that
soon,.
C
A
I
like
the
idea
of
asking
outside
of
git
lab
too.
I
think
we
all
have
a
pretty
big
network
of
engineers
that
we
could
get
their
opinions
on,
because
we've
all
been
very
git
lab.
I
get
loud
for
git.
A
A
Okay,
since
alan
has
gone
and
kicked
all
kinds
of
butt
with
our
jira
issue
creation
mvc
and
has
a
really
great
approach
on
how
to
bring
value
to
our
customers
fast.
I
wanted
to
add
this
agenda
item
to
see
how
we
can
all
contribute
to
this.
We've
got
bandwidth
in
135,
especially
for
the
front
end
team.
I
know
that
alan.
A
What
you've
proposed
is
not
exactly
what
was
in
the
design
issue,
but
I
think
it's
mostly
a
question
then
for
matt
and
andy
around
you
know
what
areas
do
we
still
want
to
try
and
focus
changes
or
our
time
on
in
13.5,
if
any?
Otherwise,
we
can
look
forward
and
start
to.
You
know,
focus
more
on
breaking
down
things
like
the
book
status,
updates
or
vulnerability
manual,
vulnerability,
creation,
things
like
that.
C
Yeah
the
one
thing
I've
added
today
as
a
part
of
the
spike
investigation-
I
added
invisibility-
maybe
it's
not
really
the
best
place
to
put
it,
but
I
put
the
general
idea
after
after
the
what
the
envy
should
look
like
and
it
split
it
with
on
into
three
three
parts,
and
these
are
very
similar
to
the
parts
that
we
initially
fought
for
the
for
the
original
implementation
with
the
creating
jira
issue
internally
and
then
linking
them.
So
the
first
one
is
configuring.
C
This
is
nothing
has
changed
in
the
embassy
and
then
we
see
I've
created
from
what
is
in
the
designs,
because
it's
actually
it's
the
same,
there's
no
change
at
all.
I
I
initially
thought.
Maybe
we
could
simplify
it.
C
Like
saying
I
I
said
about
this
input
field,
but
after
short
investigation,
it
made
no
sense
because,
because
it's
just
simpler
to
just
render
the
drop
down-
and
in
my
demo
I
I
was
using
radio
buttons,
because
I
didn't
want
to
spend
a
lot
of
time
trying
to
to
improve
it,
but
but
yeah
it's
actually.
It
will
look
the
same
with
drop
downs.
The
second
one
is
allow
user
to
create
jira
issue
like
on
the
single
vulnerability
page.
C
We
need
to
take
a
look
at
other
pages
when
we
can
create
issues,
but
I
believe
we
could
start
with
this
one.
As
a
first
item
now,
the
and
the
only
thing
that
needs
to
be
discussed.
Maybe
it's
how
to
relate
issue
between
jira
and
the
single
vulnerability,
because
it's
hard
actually,
if
you
just
do
like
click
and
it
will
create
an
issue
in
jira-
there's
no
way
that
we
can
get
that
link
back.
C
So
we
need
to
either
ask
the
user
to
to
bring
us
the
link
to
the
issue
that
they
were
just
created
or
or
we
can
somehow
hack,
hack,
it
or
just
add
appends
to
the
string
in
in
summary,
like
gitlab
v12,
something
that
the
id
of
the
vulnerability
and
then
we
can
easily
search
through
vulnerabilities,
create
like
through
issues
created
for
a
given
vulnerability
in
jira.
So
that's
that's
the
second
effort
that
will
be
the
easiest
one,
because
we
already
have
the
way
to
display
jira
issues
in
gitlab,
so
we'll
just
reuse.
C
B
Ellen
I
was,
I
was
curious,
does
jira
it's
been
a
long
time,
so
they
looked
at
them?
Do
they
have
any
sort
of
like
callback
url
where,
if
we
were
to
pass
that
in
the
query
string
that
on
submit,
we
could
actually
get
a
ping
back
to
like
a
web
hook
or
something
on
our
side.
C
I'm
yeah,
I'm
pretty
sure
they
have,
because
the
whole,
like
the
applications
that
they're
allowing
to
create
the
whole
third
party
integrations,
are
based
on
that.
But
but
this
will.
I
believe
this
will
either
require
lots
of
work
on
the
configuring
digital
instance
or
we'll
need
to
officially
register
the
add-on
to
jira
and
go
to
the
true
pro
like
to
the
process
of
to
to
be
able
to
quickly
do
that
that
that's
what
I
know
from
what
I
did
with
jira.
B
Gotcha,
okay,
I
was
curious
because
I've
seen
it's
not
very
common.
I
think
I
think
this
digital
river
that
used
something
like
this,
where
you
could
actually
provide
in
the
inbound
query
string
a
callback,
url
parameter
and
whatever
you
put
in
that
particular
whatever
the
value
was,
whenever
you
finish
the
form
submission
it
would
actually
just
make
a
ping
to
that
url.
So
there
wasn't
any
configuration
necessary,
so
you
could
put
anything
you
wanted
inbound.
I
didn't
know
if
jira
had
something
like
that.
B
A
B
A
A
Okay,
so
ellen,
I
think
this
is
an
amazing
spike.
I
think
what
you
did
here
as
far
as
creating
an
implementation
plan
is
exactly
what
the
template
for
technical
spikes
asks
for,
and
it's
going
to
be
very
clear
for
whoever
comes
through
to
help
do
the
planning
breakdown
to
look
at
this
and
help
create
the
issues.
A
So
moving
forward,
you
know
we
did
already
create
a
couple
of
sub
epics
under
the
the
parent
epic
that
one
I
think
we
should
adjust
to
fall
into
that
I've
asked
daniel
to
help.
Do
the
front
end
planning
breakdown,
whether
alan,
if
you
want
to
take
this
and
run
with
it
or
if
you
guys
feel
like
it,
would
be
good
to
have.
Somebody
else,
take
a
look
at
your
plan
and
give
it
sort
of
a
second
set
of
eyes
and
how
they
would
break
it
down.
A
Okay,
so
I
I
guess
it's
just
it's
just
a
question
now
for
my
met
because
alan's
the
one
who
created
this
spike,
but
you
know,
given
our
planning
breakdown,
questions
and
the
progress
that
we've
made.
Do
you
guys
both
feel
confident
that
we
are
ready
to
take
that
spike
with
the
progress
that
alan's
made
and
use
that
as
the
source
of
our
planning
breakdown?
And
then
you
know,
go
right
into
refinement
because
we
want
to
start
getting.
This
kicked
off.
D
Yeah
I
mean,
I
think,
it's
easier.
If
alan
creates
the
implementation
issues,
then
we
will
probably
check
the
implementation
issues
anyway.
Okay,.
C
Yeah,
I
believe,
as
soon
as
they
will
see
the
what's
in
the
in
the
spike
description,
I
actually
did
pretty
basic
how
frontend
work
could
be
split
it
so
so
they
he
can
just
take
a
look
and
then
that
I
hope
that
will
be
helpful
for.
A
Awesome
well,
this
is
great.
Thank
you
so
much
ellen,
it's
really
impressive
and
there's
the
demo,
so
you
haven't
seen
that
yet
take
a
look.
I
think
we
all
have
and
then
planning
breakdown.
We
still
have
about
10
minutes
of
this
call.
So
I
know
we
have
a
smaller
audience,
but
I'd
like
to
start
looking
at
this
bulk
update
and
getting
any
questions.
So
I
don't
know
if
either
of
you
guys
have
had
a
chance
to
go
through
this
design
update
design
issue.
Yet.
A
Okay,
so
maybe
that
is
that
something
you
guys
want
to
do
asynchronously
to
add
your
questions,
or
should
we
kind
of
do
a
high-level
explanation
of
it,
for
this
call
just
for
your
benefit.
Happy
too.
C
I
believe
the
title
is
self-explanatory.
I
mean
we
need
to
be
able
to
click
on
check
boxes
and
do
some
actions
with
it.
It'll
be
either
like
dismiss,
I
believe,
that's
the
first
stage
and
then
at
some
point
we're
going
to
add
more
change,
statuses
right
from
dismiss
to
confirm
to
result,
and
so
on.
A
So
we
already
have
dismissed
today.
That's
the
only
one
we
have,
so
this
is
allowing
us
to
do
the
other
status
changes.
B
Yeah,
so
it's
it's.
Extending
the
status
changes
the
the
bulk
action
itself.
The
select
is
already
in
place.
One
thing
that
we
are
adding
to
the
dismiss
is
a
sub
categorization.
So
are
you
dismissing
it
like?
Because
it's
a
false
positive?
Is
there
a
mitigating
control,
so
those
are
sort
of
predefined,
and
this
is
kind
of
one
half
of
work
that
will
eventually
we're
bringing
the
same
statuses
and
sub
statuses
over
into
the
vulnerability
detail
itself,
because
right
now
we're
just
capturing
the
status
changes,
we're
not
capturing
reasons
and
we're
not
being
consistent.
D
As
far
as
I
know,
you
can
also
dismiss
vulnerabilities,
not
vulnerabilities,
but
the
findings
from
the
pipeline
security
tab,
but
if
that
finding
is
already
related
with
the
vulnerability
from
the
security
dashboard,
so
dismissing
that
finding
will
dismiss
the
vulnerability
as
well.
Do
we
have
the
same
capability
of
selecting
the
this
subgroups
in
the
pipeline
security
tab
like
false,
positive
or
one
fix
or
whatsoever.
B
B
Don't
believe
so,
I
don't
think
we
do
yeah,
so
we
wouldn't
be
adding
it
to
that
view.
Yet
I
think
this
would
be
yet
another
thing
to
carry
over
eventually
migrating
over
the
pipeline
to.
A
B
A
A
And
we
can
come
back
to
this.
I
mean
clearly
we'll
want
some
folks
from
the
front
end
team,
but
I
wanted
to
make
sure
that
everyone's
aware
that
this
is
our
next
upcoming
priority
after
the
issue
creation,
I
think
our
13
5
milestone
got
a
little
bit
shifted
around
when
we
moved
away
from
the
the
security
widget
from
our
security
widget
work,
so
we're
picking
up
some
work,
mid
13-5,
which,
as
long
as
things
are
refined
and
the
team
is
comfortable
with
them,
I'm
comfortable
with
that.
I
don't
know
tiago's
or
not.
A
So
do
you
guys
want
we
can?
We
can
leave
this
one
on
the
agenda
to
make
sure
that
folks
have
more
time
to
review
it,
and
then
we
have
more
voices
to
determine
whether
this
is
ready
to
be
moved
on
to
planning
breakdown.
Do
you
have
any
gut
feelings
around
our
questions
of?
Are
the
requirements
clear
enough
to
understand
the
intent
of
the
request?
A
I
just
want
to
make
sure
that
if
any
of
these
are
a
big,
no,
we
can
work
on
getting
an
answer
for
them.
Before
we
talk
again,
do
we
understand
the
dependencies
of
the
work
to
be
accomplished?
I
don't
think
there's
any
work
outside
of
our
team
or
database
changes
or
anything
like
that.
A
Obviously,
documentation
changes,
I'm
not
sure
about
end-to-end
testing
changes.
Those
are
two
items
that
I
want
to
keep
putting
forward
earlier
in
the
process.
What
are
your
thoughts
about
end-to-end
tests
for
something
like
this?
I
don't
believe
this
is
necessarily
something
that
will
has
covered
today
in
an
end
test
and
I'm.
A
So
will
meek
is
our
sct
and
from
my
conversations
with
him
he
does
own
a
set
of
end-to-end
automated
tests
that
run
outside
of
the
standard,
mr
pipeline,
but
they
run
on
a
regular
basis
and
he
handles
the
triage
of
those.
So
he's
brought
into
our
attention
some
production
issues
and
stuff.
Recently,
I
think
we
can.
A
I
think
we
can
improve
and
be
more
efficient
about
how
that
works
and
be
more
involved
in
it.
But
as
of
right
now,
the
plan
is
to
just
mention
him
sort
of
at
this
planning
breakdown
time.
If
we
think
that
something
is
a
large
enough
or
warrants
consideration
for
or
we
think
there
already
are
end
to
end
tests-
and
I
think
it'd
be
good
to
have-
will
maybe
come
to
one
of
our
one
of
these
calls
because
he
is
over
all
of
secure,
and
that
includes
start
insights.
A
And
then
the
other
questions,
research,
matt,
the
research
solution,
validation.
I
think
we
should
remove
this
question
because,
if
you're
bringing
something
to
planning
breakdown,
I
think
the
assumption
is
that
that's
already
been
done.
But
our
third
question
for
planning
breakdown
is:
is
research
and
solution?
Validation,
complete.
A
Third
question
we
have
for
planning
breakdown
is,
is
research
and
solution,
validation,
complete
and
I
have
an
italics,
but
the
top
potentially
removed
this
question.
I
guess
I'm
of
the
opinion
that
if
something's
made
it
to
the
planning
breakdown
stage
to
get
to
this
point
in
the
conversation
that
you
and
andy
have
decided
that
it
it's
a
customer
need
and
that
you're
done
with
that.
A
All
right,
so
I'm
just
gonna,
take
that
question
off
the
less
questions
the
better
and
then
the
last
question,
then,
is
it
small
enough
to
complete
in
one
iteration
and
again,
I'm
not
asking
for
a
concrete
answer
to
all
of
this,
but
you
know
your
gut
feeling
if
we
weren't
looking
at
anything
else,
do
you
feel
confident
that
this
would
be
an
issue
that
we'd
be
able
to
do
in
one
milestone.
B
C
It's
already
yeah,
the
graphql
allows
you
to
send
multiple,
like
in
one
request,
to
be
able
to
do
like
bulk
update
or
something
like
that.
So
we're
already
doing
that
for
for
the
dismiss,
so
so
no
need
for
do
any
additional
things
for
for
like
resolving
and
other
other
types
of
statuses
for
vulnerability.
A
Okay,
well
that
helps
with
how
to
move
forward.
We
can
take
some
of
this
asynchronously,
I
believe,
with
the
front-end
team,
and
I
will
follow
up
on
that.
B
C
Okay,
so
then
yeah,
because
right
now
we
added
the
maybe
not
the
undo
but
being
able
to
bring
the
vulnerability
back
to
like
how
is
the
state
called
to
the
initial
state
that
detects
it
yeah
so
yeah?
Definitely
if
you
want
to
undo
so
that
means
removing
all
the
comments,
or
are
we
going
to
save
save
that
information
that
it
was
someone
just
reverted
that
to
the
previous
state
yeah.
B
So
this
is
it's
taking
the
last
change
and
reverting
that
last
change,
so
you
may
have,
for
instance,
a
mix
of
statuses.
You
could
have
some
detected,
some
confirmed,
maybe
some
remediated.
Let's
say
you
accidentally
hit
the
button
and
hit
dismiss
and
realize
oops.
I
didn't
mean
to
do
that.
Everything
should
go
back
to
the
previous
detected
confirmed
remediated,
whatever
state
it
was
in
before,
but.
B
D
D
C
Yeah,
maybe
maybe
for
the
initial
for
this
release.
We
can.
We
can
have
everything
without
the
undo
and
then
do
the
undo
in
the
next
release
so
because
I'm
not
sure
if
we'll
be
able
with
jira
and
with
this
bulk
update
to
do
it
this,
both
in
one
release,
I'm
not
sure
how
it's
our
workload
right
now
I
don't
see
lots
of
items
but
yeah.
D
Whether
it's
just
like
showing
a
confirmation
message
to
the
user
like
hey,
are
you
really
sure
you
want
to
like
dismiss
x
amount
of
vulnerabilities?
I
mean
if
the
user
clicks?
Yes,
then
I
I
don't
know
like
because
this
will.
This
will
put
lots
of
obviously
complexity
on
the
backhand
side
and.
A
B
Well,
I
mean
I
don't
want
to
rule
it
out.
I
think
the
met
actually.
Would
you
no,
I
I
would
say.
Could
you
leave
that
as
a
comment
for
andy
on
the
issue
and
yeah,
I
think
that's
a
fair
explanation,
because
you're
right
we'll
have
to
keep
a
record
of
that
transaction
that
we
can
roll
back
as
opposed
to
just
not
taking
the
action
until
we
ask
the
user,
did
you
really
mean
to
click
the
thing.
B
And
there
is
some
pres,
I
think,
there's
a
there
is
precedent
for
that,
too.
Like
issue
templates,
if
you've
ever
opened
an
issue
and
you've
changed
the
template,
it
actually
asks
you
do.
You
want
to
apply
this
before
you
actually
go
forward
with
it.
So
I
think
there
are
definitely
ui
ux
paradigms
that
we
can
draw
from.
A
I
think
that
particular
question
and
suggestion
from
I
met
it's
a
lot
of
or
there's
there's
a
lot
of
weight
on
that.
If
we
do,
we
can
move
forward
with
a
confirmation
instead
of
an
undo.
It's
a
it's
a
much
different
estimate
on
how
much
work
it
is.
So
maybe
can
you
make
sure
that
you
add
that
question
to
the
security
or
to
the
design
issue
versus.
B
A
And
even
if
just
adding,
even
if
they
still
want
the
undo
of
adding
the
confirmation
as
a
safety
measure
until
that's
in
place-
and
I
don't-
I
don't-
want
to
speak
for
the
full
front-end
team,
but
I
don't
feel
like
that
would
be
a
huge
effort
so
and
we
are
at
the
end
of
our
half
hour,
I'm
glad
we
made
it
through
this
issue.
We've
got
a
couple.
A
We
want
to
make
sure
that
we're
still
moving
forward
with
our
planning
breakdown
and
our
you
know
pre-milestone
tasks,
but
still
giving
people
a
place
to
come
and
ask
those
questions.
So
if
you
can
attend
that,
I
think
I've
alternated
them
between
earlier
and
later.
In
the
day,
it
would
be
helpful
to
have
engineers
from
the
team
there
to
help
answer
questions
too
so
they're
on
the
threat
management
sub
department
calendar
a
little
plug
for
that
there
all
right.
Thank
you,
everyone
for
your
time,
we'll
talk
soon.