►
From YouTube: Threat Insights - Weekly Group Discussion - 2020-05-05
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
I
believe
I
do
so
a
topic
that
came
up
in
the
meeting
that
we
had
with
secure
last
week.
That
olivier
was
asking
about.
I
think
david
reiterated
the
importance
of
achieving
parity
here.
Is
this
ability
to
handle
vulnerabilities
differently
when
they
have
a
remediation
available?
So
if
you
look
at
this
issue,
this
is
and
it's
I
wrote
it
a
little
intentionally
open
because
I
think
there's
some
confirmation
that
needs
to
happen
both
on
what's
coded
right
now
and
what
the
expected
behavior
is.
B
B
If
anyone
on
this
call
had
a
understanding
that
we
should
be
treating
the
issue,
creation
or
sorry
treating
the
vulnerabilities
differently
based
on
whether
they
had
a
remediation
or
not
and
going
through
a
different
path
to
be
able
to
resolve
with
an
mr
speak
up
now
and
help
us
help
educate
us,
but
the
intention
of
this
ticket
is
to
you
know,
understand
what
the
expected
behavior
is
what's
already
in
place
today,
because
it
does
look
like
there
is
some
code
in
place
to
handle
this
situation,
but
from
alexander
and
I's
digging.
B
It
was
more
of
kind
of
a
static
message
that
was
displaying
back
to
the
user
and
alexander
had
some
other
findings
already,
which
is
part
of
why
he's
assigned
to
this
I've
already
assigned
this
to
him
and
jonathan
we've
pulled
this
into
13.0
again.
This
is
trying
to
achieve
parity
and
it's
a
late
arriver
in
our
milestone.
So
I
wanted
to
bring
it
to
everyone's
attention.
C
I
haven't
gotten
a
chance
to
look
at
it
much,
but
based
off
what
alexander's
been
saying
and
just
my
understanding
of
the
code
bases
I
I
would
be
surprised
that
the
backend
work
isn't
already
available
to
make
this
happen
on
the
front
end.
And
since
it's
already
you
know
the
features
in
place.
You
know
I'll
take
a
look
some
more
to
make
sure
and
confirm
on
that
and
work
with
alexander,
if
there's
any
additional
work
that
needs
to
happen,
but
awesome,
hopefully
that
we
already
have
the
back
end
in
place
in
that.
D
Yeah,
I
think
the
just
from
my
initial
debug
findings.
It
looks
like
that
the
endpoints
are
there.
Maybe
the
the
back
end
needs
to
send
up
a
little
bit
more
data
in
the
but
in
the
object
initially
sent,
but
I
think
the
end
points
are
there
and
I
should
be
able
to
get
started
on
this
in
the
front
end
side.
E
I
think
we'll
have
to
check
on
what
happens
when
a
merge
request
has
already
been
created.
What
do
we
show
in
that
button?
Do
we
just
remove
that
line
from
the
list
and
that
drop
down
that
ability
to
create
another
merge
request
so
right
now
we
have
that
can
only
create
one
issue,
but
if
you
create
a
merge
request,
we
still
want
them
to
have
the
ability
to
create
an
issue.
So
we
don't
want
to
remove
the
whole
button,
but
we
can
talk
that
out
more
based
on
any
investigation
into
what
happens
today.
B
And
we
can
see
what
happens
today
by
looking
at
the
pipeline
view
is
something
that
olivier
has
pointed
out
to
us.
So
he's
provided
us.
You
know
some
test
projects,
hopefully
that
information
is
all
available
in
the
issue
at
this
point,
if
you're
not
finding
it,
let
me
know
I
can
it's
kind
of
all
over
the
place.
So
thank
you,
alexander
and
jonathan
and
andy.
You
know.
B
I
know
that
13.0
is
supposed
to
be
a
lot
of
like
cleanup
and
debt
resolution,
but
clearly
we
need
to
kind
of
prioritize
this
higher
than
that,
because
we
don't
want
to
take
away
functionality
from
our
customers.
F
Yeah,
I
think
I
need
to
chat
with
a
few
folks
internally.
First,
I
guess
I
was
under
the
impression
that
not
a
whole
lot
of
people
would
have
been
using
it
since
the
the
scan
types
and
the
language
types
are
very
limited
right
now,
but
a
comment
from
david
was
that
there
are
some
customers
that
depend
on
this,
and
this
is
a
big
feature
for
them.
So
I
need
to
find
out
specifically
whom-
and
if
this
would
be
a
big
deal
or
not,.
B
B
I
am
going
to
say,
let's
be
safe
and
say
that
we
want
to
get
it
merged
by
the
18th
just
to
avoid
any
of
that
confusion,
which
means
that
we'd
want
any.
Mrs
to
start
in
the
reviewer
maintainer
cycle
early
next
week
and
hopefully
to
jonathan's
point.
This
is
existing
functionality.
We've
got
endpoints
available.
I
think
you
know.
A
lot
of
this
is
just
making
sure
that
we
understand
the
behavior
correctly.
A
So
is
there
anything
else
actually
going
to
actually
before
we
go
on
to
the
next
question,
which
is
related
to
anything
else
on
this
topic.
B
Keeping
us
honest
yeah
so
he's
saying
we
have
17th
in
the
calendar
for
the
cutoff
date
so
friday,
the
15th,
which
I
don't
think,
really
changes
that
way
too
much.
A
Oh,
no,
so
is
there
anything
else
that
would
stop
us
from
turning
the
feature
potentially
or
actually
stop
us
from
turning
the
feature
flood
on
the
reason
I
ask
is,
I
surely
don't
want
to
wait
till
the
last
day
of
the
release?
Nobody
was
planning
to
do
that
to
merge.
That
is
already
incorrect
if
wrong,
jonathan
or
things
have
changed,
but
you
worked
on
that
one
is
it's
already
maintainer
approved.
We
asked
them
not
to
merge
it
by
intent.
C
It
is
already
maintained
or
approved.
I
think
I'd
want
to
get
them
to
do
one
more
quick
check
over
just
to
you
know,
since
it's
been
so
long
to
just
say:
hey
you're,
still
good
on
this
or
just
because
they're
gonna,
they're
gonna
have
to
be
the
ones
who
merge
it
anyway,
but
I
bet
the
the
guy
that
the
maintainer
that
I
was
having
to
look
at
this
I'll,
just
ping
him
again
and
and
good
when
we're
ready
to
do
this.
A
You
know
a
couple
business
days
later,
so
let's
say
let's
say
we
merged
it.
I
don't
know
the
counterfeit.
Let's
say
we
merged
it
a
week
in
advance,
then
or
asked
for
it
to
be
merchant
week
in
advance,
and
let's
say
it
happens
that
day,
you
know
a
couple
days
later:
it
gets
to
prod
production
and
then
and
then
also
that
change
gets
into
the
next.
A
You
know
next
release
that
for
customers
that
are
self-hosting,
you
know,
which
was
at
least
you
know
week
to
well
week
and
a
half
later,
but
I
definitely
don't
want
to
wait
to
that.
Last
week.
All.
B
A
Some
ways
I
think
there
always
might
be
a
reason
we
didn't
know
about
this
and
we
were
ready
to
merge
with
12
10..
So
I
I
I
don't
I
we
definitely
want
to
research
it,
but
at
the
same
time
I
think
there's
always
going
to
be
a
wait.
Oh
wait.
Maybe
you
know
kind
of
kind
of
discussion
on
some
something
new
discovered
okay,
but
so,
but
we
should
definitely
at
matt
research.
Did
this
it's
matt's
decision.
B
C
Issue
too
soon,
I'm
waiting
for
the
go
ahead
for
matt.
That's
when
he
gives
me
the
go
ahead,
I'll
I'll
see.
If
I
can
get
somebody
emergent,
so
the
the
other
thing
is
we.
This
feature
is
not
going
away
in
its
current
form
correct.
So
the
the
thing
that's
not
currently
implemented
in
first-class
phones,
it's
so
it's
still
going
to
exist
in
another
like
on
the
security
dashboards,
correct,
so.
C
The
feature
we
were
just
discussing,
the
that
you
assigned
to
me
and
alexander:
that's
not
going
away.
The
current
implementation
is
not
going
away.
B
B
C
Right
right,
so,
even
if
it
wasn't
in
first-class
volumes,
it's
there
it's
a
workaround
that
they
would
have
to
do,
and
they'd
have
to
go
through
the
security
dashboards
to
do
it.
B
There's
some
confusion
there,
because
the
security
dashboards
will
be
replaced
with
standalone
vulnerabilities
and
the
functionality
that's
available
to
interact
with
standalone
vulnerabilities
is
all
customers
will
get
to
interact
with
after
that
point,
so
any
of
the
functionality.
That's
there
today
with
the
findings
back
dashboards
once
we
flip
that
feature
flag
will
either.
D
B
C
B
It's
it's
kind
of
a
and
b
right,
so
the
dashboards
that
are
there
today
that
are
findings
back,
have
its
own
features
that
are
tied
to
it.
We've
completely
rebuilt
them
with
b
now
the
graphql
standalone
vulnerabilities
back
dashboards,
and
this
is
one
of
the
features
that's
tied
to
that,
and
this
isn't
even
on
the
dashboard.
B
The
existing
one
will
go
away
in
the
new
graphql
version.
That's
backed
by
standalone
vulnerabilities
is
what
they
will
see.
There's
right
now
today,
what
might
be
causing
some
of
your
confusion.
Jonathan
is
that
there
is
a
security
dashboard
and
a
vulnerability
list.
Okay,.
B
A
So
and
I
assigned
the
little
task
in
the
google
doc
to
ross-
I
don't
know
if
he
watches
those
or
not,
but
how
about
this
is
since
we'd
want
to
merge
at
the
end
of
this
week
to
give
us
a
week
prior,
we
don't
want
to
have
to
invoke
the
the
high
priority,
merge
request
or
whatever
we're
calling
it
absolutely
not
because
we're
ready
and
it
would
be,
it
would
be
overdoing
it
for
this
and
other
things
so
the
so.
Why
don't?
A
We
do
a
sink
call
on
friday
with
jonathan
and
lindsey,
and
I
and
and
and
matt,
and
maybe
ross
too
or
basically
you
know
invite
that
invite
the
invite
the
group,
the
defense
stage
calendar,
but
in
particular
ad
ross
as
well.
Let's
just
make
a
call
on
friday
and
where
we're
at
does
that
seem
reasonable.
A
Which
would
make
it
a
couple
business
days
later,
probably
monday
or
tuesday
or
wednesday
next
week,
it'd
be
live
for
dot
com,
customers
and
then
it's
done
long
in
advance.
No,
I
don't
know
long
in
advance.
It's
done
definitely
in
advance
of
the
cutoff
for
13.0,
where
a
lot
of
people
are
expecting
the
feature
in
13
now.
B
A
A
A
Okay
sounds
good,
taking
notes
here.
Okay,
so
can
had
a
question
and
can
couldn't
make
it
today.
Does
somebody
want
to
verbalize
the
question
and
our
this
is
a
question
asked
in
slack
that
they
asked
twice,
I
think
yeah
I
could
comment,
and
so
I
just
wanted
to
add.
It
was
a
good
time
to
add
it
to
this
discussion,
so
we
could
make
sure
we
answered
it
so.
C
Go
ahead,
I
could
take
this
one
since
so
he
was
saying,
as
far
as
I
understand,
first
class
vulnerabilities,
oh
man,
alan
alex
typing
and
he's
covering
up
with
the
text.
C
As
far
as
I
understand,
first
class
vulnerabilities
is
an
abstracted
version
of
one
or
more
vulnerability
occurrences.
If
that
is
the
case,
why
are
we
adding
occurrence
data
to
first-class
vulnerabilities?
I'm
just
gonna
stop
there
because
right
now
it
is
a
one-to-one
relationship,
and
we
have
discussed
this
in
the
past.
I've
actually
addressed
it
with
can
in
slack
in
the
past.
On
that
thread
that
I
followed
up
on.
It's
a
one-to-one
link
right
now.
C
A
So
thanks
jonathan,
so
it
looks
like
it's
been
answered
in
the
past
as
well.
I
don't
know
about
that
comment,
but
that's
good
to
know
as
well
could.
E
You
just
copy.
A
And
paste
that
into
that
the
recent
slack
conversation
interesting.
I
will
do
that
and.
C
A
A
A
So,
what's
next.
B
Here
took
it
upon
myself
to
add
a
couple
of
issues
for
planning
breakdown,
so
matt.
I
hope
you
don't
mind
all
right,
a
couple
of
other
things
that
have
come
up
and
just
now
that
we
have
the
demo
dashboards
working
in
production,
it's
really
fun
to
go
out
there
and
play
around
with
them.
But
it's
really
come
to
my
attention-
and
I
talked
to
andy
about
this
as
well-
that
the
the
infinite
scroll
is
less
than
ideal,
especially
with
the
multi-select
of
vulnerabilities.
B
It
also
limits
the
customer
and
seeing
how
many
results
there
are.
I
think,
there's
some
other
reasons
why
the
infinite
scroll
is
not
something
we
want
to
stick
with.
It
was
something
we
moved
to
as
a
result
of
the
graphql
limitations
at
the
time,
and
andy
was
okay
with
that,
but
I
think
we
wanna
based
on
our
conversations.
We
want
to
start
looking
at
a
better
solution
and
you
know
I
know,
there's
been
some
conversations
in
the
issue
since
I
put
these
on
the
agenda.
B
Avielle
brought
to
our
attention
some
performance
guidelines
around
why
we
wouldn't
want
to
use
the
typical
number
based
pagination
that
we
have
on
the
existing
security
dashboard
today.
So
I
created
two
issues
here
and
this
second
one
is
maybe
the
one
that
we
should
be
looking
at,
because
I
think
that
and
andy
I'm
not
trying
to
speak
for
you
or
anything,
but
it
sounds
like
there's
still
some
investigation
that
needs
to
go
on
about
what
the
best
design
is
for
what
we
want
this
pagination
or
scrolling
to
look
like,
but
your
temporary
issue.
E
Really
we
could
yeah.
I
think
we,
I
think
we
need
to
know
what
the
trade-off
is
between
performance
and
experience
when
researching
pagination,
there's
a
lot
of
benefits
to
having
numbers
in
the
pagination
and
being
able
to
link
two
pages
and
all
that
stuff.
But
there's
also
the
performance
drawbacks
and
there's
gonna
have
to
be
a
balance,
because
if
it
doesn't
load,
pagination
doesn't
matter
so
for
now,
I
think
we
can
pin
the
the
table
at
least
so,
allow
the
list
to
scroll
infinitely
but
keep
the
filters
and
everything
pinned
up
top.
B
And
I
know
this
isn't
much
of
a
planning
breakdown
issue,
because
it's
relatively
small
in
size
when
I
originally
put
it
under
plenty
breakdown.
It
was
to
talk
about
the
bigger
issue
around
moving
away
from
the
infinite
scroll,
but
again,
like
I
said,
since
I've
done
that
there's
been
some
realizations
that
maybe
there's
some
more
discussion
that
should
happen
there.
So
if
this
pinning
issue
were
to
make
it
into
13.1,
is
there
anyone
that
has
questions
so
going
back
to
our
agenda?
What
planning?
What
planning
breakdown
questions
we
ask?
B
Are
the
requirements
clear?
Do
we
know
the
boundaries
of
our
work
and
is
the
research?
Is
the
solution
validation
complete?
So
do
we
feel
that
this
temporary
solution
of
pinning
the
items
to
the
top
of
the
dashboard
is
something
that
you
guys
would
be
confident
on
the
size
and
pulling
it
into
an
iteration?
And
you
have
all
the
answers?
B
This
is
mostly
front-end
issues,
so
I'm
kind
of
looking
at
alexander
and
swash.
You
guys
have
any
questions
about
this
temporary
one.
The
second
one
listed
here,
nope
all
right
cool
that
was
it
and
then
we'll
revisit
the
pagination
question.
Once
andy's
had
some
more
time
to
look
into
it.
F
Oh
yeah,
I
saw
there
was
a
question
about
that
one.
So
as
far
as
I'm
concerned,
it's
important
but
not
urgent.
I
would
much
rather
not
just
the
team,
but
myself
have
been
focused
on
getting
this
out
the
door.
So
I
know
we've
got
company-wide.
There
are
some
okrs
around
having
these.
If
folks
haven't
heard
about
it
yet
north
star
metrics,
it's
just
it's
kind
of
like
a
the
one
number.
F
F
So
I
just
need
to
put
in
issues
to
make
sure
that
we've
got
the
right
things
in
place
so
that
the
data
the
telemetry
teams
can
track
that
we've
already
decided
kind
of
on
the
product
and
with
the
telemetry
team
that
the
right
thing
to
track
for
us
right
now,
since
we
don't
have
a
lot
of
pieces,
is
just
number
of
dashboard
views.
So
we
want
to
see
our
people
interacting
with
it
and
we
want
to
see
that
go
up
over
time,
that'll
be
across
all
the
dashboards.
F
So
I
will
be
working
on
that
for
hopefully
next
week.
So
we
can
see-
and
oh
yes,
alexander's,
asking
about
north
star
metrics
and
yeah
there.
It's
a
whole
thing
that
comes
from
if
you're,
interested
growth,
hacking
and
also
hacking
growth
to
confusingly
named
books,
kind
of
socialize
that,
but
it's
generally
about
trying
to
take
a
very
data-driven
growth
approach
to
product
management
development.
And
so
it's
just
kind
of
trying
to
keep.
F
You
pointed
in
the
right
direction
by
looking
at
the
metric
that
matters
and
these
will
evolve
over
time,
but
there's
a
lot
of
holes
in
the
data
that
we
collect
and
the
visibility
that
we've
got
both
for
com,
as
well
as
the
self-hosted
folks
through
the
usage
ping.
So
there's
big
efforts
to
clean
that
all
up
and
make
sure
that
we've
got
these
in
place,
at
least
at
some
minimal
amount
for
all
the
stages
and
all
the
groups.
A
Sorry
matt,
so
what
have
you-
and
I
should
probably
know
this
already
but
I'll-
ask
you
anything
about
it:
singers.
What's
the
primary
north
star
metric
for
vulnerability
management,
is
it
people
using
the
vulnerability
management
features
or
have
you
have
you
settled
on
that
or
still
thinking
about
it.
F
Yes,
so
for
right
now,
since
it's,
what
we're
trying
to
do
is
encourage
use
of
the
product
overall
and
then
by
stage
I'm
settling
on
something.
That's
actually
very
close
to
our
don't
ask
me
to
say
what
this
is
smile.
I
can
never
remember
what
it
stands
for.
I
think
it's
stage
monthly,
active
users
so
basically
a
view
of
the
dashboard,
because
the
dashboards
are
not
necessarily
something
that
you
would
go
to
by
accident,
probably
more
than
once.
A
F
Particular
the
security
dashboard,
so
that
actually
means
the
project,
the
group
and
the
instance
level.
So
it's
all
three
of
them
aggregated
up,
so
the
single
number
is
number
of
dashboard
views.
Then
you
can
have
sort
of
supporting
metrics,
which
will
be
the
breakdown
of
the
individual
ones.
So
you
can
have
a
little
bit
more
kind
of
nuanced
view
of
things.
But
ultimately
is
we
want
people
to
use
the
dashboards?
The
dashboards
is
a
pretty
good
proxy
for
people
actually
interacting
with
the
vulnerability
management
piece
of
the
product.
A
Sounds
great,
I
think
we're
going
to
be
based
on
a
number
of
projects
just
on
on
gitlab.com
hosted
that
use
that
that
do
vulnerabilities
detect
vulnerabilities
in
some
way
you
know,
eat
one
or
more
secure
state
secure
features
in
the
secure
stage
that
went
up
like
10
from
last
month
this
month
and
that's
a
consistent
trend
of.
I
think
it's
in
the
order.
Magnitude
like
1,
500,
1700
projects
unique
projects
every
month
that
do
some
kind
of
scanning
and
they're
doing
it.
A
For
reason,
is
they
want
to
find
the
vulnerabilities
and
then
try
to
resolve
them
prior
to
viewing
them
to
prioritize
them?
Is
in
the
dashboards.
So
I
think,
we'll
see
significant.
I
think
we
already
have
significant
usage
of
the
non-standalone
vulnerabilities
and
when
we
launch
standalone
we're
going
to
see
you
know
very
high
usage
based
on
that
we'll
see,
but
it's
good
stuff
thanks
man,
anybody
else
have
any
thoughts
or
questions
for
matt
on
that
no.
F
F
The
philippe
says,
he's
got
really
noisy
kids,
okay,.
B
F
That
wasn't
the
question,
though
no
I
know
he's
asking:
if
we
should
track
the
number
total
number
of
vulnerabilities
as
tracking
the
views
might
be
tricky.
I
guess
I
can't
say
whether
or
not
views
is
tricky
or
not.
I
would
assume
that
that
would
be
sort
of
a
you
know
either
we
can
do
it
on
click
of
the
the
actual
link
to
the
menu
or
to
the
dashboard
itself,
or
you
know,
page
load,
but
the
reason
to
not
track
the
total
vulnerability.
So
that
was
something
that
was
kind
of
kicked
around.
F
A
part
of
that
is
the
scanner
the
individual.
Secure
teams
are
going
to
be
tracking
some
similar
metrics
on
their
side
as
well.
I'm
also
uncomfortable
with
that
as
a
metric,
because
I
think
that
may
give
us
a
false
sense
of
direction
of
use
and
utility
of
the
product.
It
could
mean
that
we're
just
seeing
more
new
projects.
F
One
time
it
could
mean
that
people
are
testing
more
things
with
more
vulnerabilities,
but
I
think,
what's
more
challenging
with
that,
one
is.
If
we're
seeing
a
consistent
uptake
in
the
product
usages
itself
over
time,
I
would
expect
vulnerabilities
per
project
to
actually
go
down
as
you're,
not
introducing
new
vulnerabilities
as
much
as
that
initial
scan
of
a
new
project,
and
so
I
don't
think
it
will
be
a
clear
indicator
of
what
direction
use
of
the
vulnerability
management
piece
itself
is
undergoing.
F
That's
a
really
good
point
about
the
api,
though,
but
I'm
willing
to
kind
of
discount
people,
interacting
with
the
vulnerabilities
and
the
dashboard,
like
kind
of
the
backing
pieces
to
the
api
for
the
short
term.
The
other
thing
that's
really
important
to
know
about
the
northstar
metric
is,
it
will
evolve
over
time
and
it's
not
the
only
data
point
that
we
should
be
capturing.
F
It's
just.
What
is
the
thing
that
we
should
look
at
right
now
to
see
if
we're
trying
to
align
with
general
the
general
company
direction,
which
is
trying
to
encourage
usage
across
stages?
So
these
are
all
things
that
we
can
and
should
look
to
put
the
instrumentation
in
place
with
the
telemetry
team
over
time.
F
E
F
We
will
become
the
data
we
want
to
track.
Yes,
we
will.
I
should
point
out
too
one
of
the
other
challenges.
Is
we
already
get
a
very
limited
amount
of
data
from
our
self-hosted
customers,
which
tend
to
be
the
bulk
of
our
paid
customers
and
the
ultimate
side,
which
is
the
data
we
really
care
about?
We
have
a
lot
more
limitations
right
now
and
what
we
can
actually
collect
for
those
that
even
leave
the
usage
ping
on.