►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
Welcome
to
the
threat,
insights,
weekly
group
meeting,
to
repeat
what
I
just
said.
We
have
one
issue
on
our
agenda
today
and
it's
from
savage
which,
who,
unfortunately,
is
not
here-
and
this
was
an
issue
he
created
around
some
tech,
debt
and
jonathan-
has
already
participated
in
this
conversation
so
I'll.
Let
him
sort
of
explain
the
concept
for
us.
B
All
right,
we've
actually
had
a
lot
of
conversations
in
an
issue
that
was
opened
previously
in
this
one
as
well.
That
was
it's.
It's
pretty
similar
in
terms
of
the
fact
that
we
have
this
vulnerabilities
call
and
it
only
it
only
returns
the
vulnerabilities
that
are
set
up
in
the
security
dashboard,
which
is
not
what
you
might
expect.
B
If
you
want
to
include
the
projects-
and
it
was
throwing
me
for
a
loop,
and
so
I
had
opened
up
an
issue
to
actually
add
in
a
filter
based
on
groups
and
or
projects
which
is
the
same.
It's
it's
basically
a
duplicate
issue.
Daniel
had
had
some
suggestions
in
there
as
well
on
this
one,
but
a
lot
of
a
lot
of
the
mouse.
B
A
lot
of
conversation,
the
other
one,
actually
ended
up
around
how
we
were
going
to
name
things,
and
I
think
matt
just
got
tired
of
that
conversation
as
well.
B
It's
like
just
name
it
something,
but
savas
suggested
having
one
vulnerabilities
call
and
getting
rid
of
the
project
vulnerabilities
and
the
group
dot
vulnerabilities
and
the
pipeline
security,
dashboard
security.
Finding
security
report
findings
to
have
just
one
vulnerabilities
call
daniel
had
some
input
suggesting.
A
A
To
add,
is
you
know,
we're
in
the
process
of
this
migration
of
the
pipeline
vulnerability
report
to
use
graphql
and
shared
components
wherever
possible.
Today
we
have
to
make
the
same
changes
in
multiple
places,
because
those
are
totally
different
vulnerability
lists,
even
though
to
the
customer
and
the
the
design
vision.
They'll
be
the
same.
So
a
lot
of
this
is
coming
out
of
the
fact
that
we
have
to
treat
findings
and
vulnerabilities
very
differently.
A
So
this
it
was
also
in
slack,
and
I
don't
have
that
message.
I
think
maybe
it's
an
issue
handy,
but
this
is
the
link
here
in
the
agenda
to
savasha's
related
description,
which
is
the
on
the
one
to
many
topic
after
talking
to
thiago
about
this,
because
the
question
that
savage
had
was:
do
we
delay
this
conversion
to
graphql
until
we
can
unite
the
data
behind
findings
and
vulnerabilities
so
that
we
don't
have
to
incur
the
debt
of
the
conditionals
in
the
front
end?
A
That
says,
if
it's
a
finding
to
this,
if
it's
a
vulnerability,
do
that
tiago
was
concerned
about
the
effort
around
doing
that,
and
I
think
it
was
all
wrapped
into
this
one-to-many
conversation,
which
I
don't
totally
get
and
he's
not
here
to
speak
to.
B
No,
my
understanding
is
we're
not
doing
anything
with
monta
mini
at
this
point.
G
E
A
D
D
If
a
user
interacts
with
the
finding,
like,
I
I
don't
know,
tries
to
dismiss
it
creates
an
issue
for
it.
We
automatically
promote
it
to
vulnerability,
so
we
will
have
a
huge
number
of
vulnerabilities
and
a
small
number
of
smaller
number
of
findings,
which
would
be
just
the
things
that
we
show
in
the
pipeline.
B
And
the
other
thing
is
that
they're.
Actually,
if,
unless
this
pipeline
is
on
the
default
pipeline,
there
are
no
findings.
Everything
is
everything
comes
from
the
report
unless
it's
the
default,
the
the
default
pipeline.
So
that's
one
of
the
reasons
why
I'm
saying
I
don't
think
we
can
get
rid
of
the
the
pipeline
security
reports
findings
because
it's
it's
not
it's
not
the
findings
themselves.
It's
the
security
report.
That's
getting
sent
back.
D
Exactly
we
could,
I
believe
we
could
unify
the
security
center
group
level,
security,
dashboard
and
project
security.
Dashboard
queries,
the
pipeline
security.
Dashboard
query
is
probably
going
to
have
to
remain
a
different
query
altogether.
D
D
As
a
namespace,
we
can
determine
if
it's
a
group
or
if
it's
a
project
and
like
limit
the
vulnerabilities,
returned
either
way
and
the
security
center
is
basically
instance-wide
vulnerability
report,
if
I
recall
correctly
so
I
think
we
could
just
we
could
just
unify
those
queries,
but
the
pipeline
security
dashboard
is
going
to
have
to
remain
a
different
query,
since
we
do
not
have
vulnerabilities
persisted
in
the
pipeline
security
tab,
we
just
parsed
the
report.
As
jonathan
said.
A
So,
from
a
customer's
perspective,
they
don't
know
the
difference
really
between
a
finding
and
a
vulnerability
and
from
so
from
the
apis
and
from
the
front
end.
I
think
the
ultimate
goal
would
be
to
have
them
delivered
uniformly
right,
so
we
don't
have
to
modify
the
data
a
lot
to
display
them
uniformly
and
so
that
the
customer
would
see
them
in
the
same
data
sets.
Does
that
seem
accurate.
B
Yeah
I
mean
yeah,
I
mean
I
I
I
get
that
and,
and
I
you
know
see
you
know
we
wanted
everything
to
be
displayed.
The
same.
D
Basically,
vulnerability
object
is
a
superset
from
from
the
finding
itself.
So
if
we
don't
convert,
convert
the
findings
to
vulnerabilities,
then
we
can't
present
everything
uniformly,
because
some
of
the
information
is
not
available.
Yet
at
this
point,
until
the
user
does
any
like
interacts
with
defining
itself
like
creating
an
issue
dismissing
it
doing
whatever
to
it,
it's
going
to
remain
a
finding.
D
B
And
the
downside
is
that
if
we
do
that
we
are
creating
a
absolute
ton
of
vulnerabilities
thinking
about
like
the
get
life
project
yeah.
The
other
thing
is
that
well.
A
Hold
on
jonathan,
can
I
ask
you
a
question
before
you
move
on
from
that
with
a
one-to-many
conversation?
Maybe
this
is
where
it
comes
in,
because
there's
not
a
ton
of
vulnerabilities,
there's
a
ton
of
findings,
and
there
might
be
a
lot
of
findings
that
point
to
one
vulnerability
right.
You
find
one
vulnerability
in
multiple
places
in
your
your
code,
so
once
they're
distilled
down
to
just
the
vulnerability
set,
it's
not
as
large
as
if
you
had
a
unique
vulnerability
for
every
finding.
A
So
that's
that's!
What
I'm
talking
about
they're,
not
talking
about
findings
like
unique
vulnerabilities,
whereas
if
multiple
findings
pointed
to
one
vulnerability
like,
depending
on
where
they're,
where
they're
at
in
the
code
or
how
they're
they're
found,
but
at
the
core
they're
pointing
to
one
vulnerability.
Wouldn't
that
reduce
that
number
considerably.
A
D
D
And
the
one
too
many
discussion,
it
has
been
popping
up
very
recently,
and
this
is
I'd-
call
it
a
technical
depth.
At
this
point.
Some
decisions
have
been
made
in
the
past,
which
the
the
initial
idea
of
the
vulnerability
inside
sorry
threat
insights
was
to
have
multiple
findings
that
could
be
belong
to
single
vulnerability.
A
And
to
be
completely
honest,
I'm
not
sure
why
this
conversation
got
attached
to
this
a
few
weeks
ago.
This
is
just
where
savash
brought
this
conversation
out
of
slack
again
and
that's
why
I
pointed
to
it
here.
So
I'm
clearly
out
of
my
element
at
this
point
and
not
fully
able
to
drive
this
conversation
from
the
front-end
side.
A
So
I
think
at
this
point,
savasha's
issue
is
written
more
specific
to
what
mihao
had
said
around
being
able
to
reduce
the
number
of
endpoints
that
we
have
being
able
to
unify
the
project
group
and
security
center.
Sorry,
I'm
still
struggling
with
the
wording
there
and
the
unification
of
findings
and
vulnerabilities
is
a
different
topic.
I
guess,
if
we
leave
the
pipeline
api
the
same,
we
just
have
the
front
side.
Implementation
is
not
as
clean
as
it
could
be.
B
Right,
I
mean
and
remember
we
don't
create
findings
for
every
pipeline.
B
And
so,
if
we
did,
I
don't
I.
I
really
don't
think
that
you
again
if
we
were
to
pull
a
pipeline,
that's
not
a
default
pipeline,
there's
no
associated
ids
to
anything,
and
so
you
wouldn't
be
able
to,
except
for
the
finding
uuid.
I
think
that
would
be
the
only
thing
that
gets
pulled
and
that's
automatically
generated.
A
B
Okay,
so
it
would
be
a
different
set
of
data
that
comes
back
from
those
pipelines,
and
that
comes
back
for
the
vulnerabilities.
B
A
A
A
A
The
definitions
of
them,
but
it'd
be
great
to
have
a
better
explanation
and
if
somebody
would
be
willing
to
put
together
a
brown
bag
or
a
video
that
walks
through
the
some
of
the
things
that
you're
talking
about
with
maybe
even
some
documentation
around
it.
That
would
be
really
helpful,
as
the
back
end
has
a
lot
on
their
plate.
The
front
end
would
like
to
be
able
to
move
forward
with
things
that
just
require
a
small
amount
of
back-end
changes,
and
this
would
really
empower
us
to
do
that.
A
So
not
asking
anyone
on
this
call
to
do
it
right
now.
I
know
that
this
topic
will
come
up
again,
but
I'm
just
putting
this
out
there
that
right,
it's
not
very
clear
right
now,
go.
D
D
Last
time
I
checked
we
were,
we
were
at
8
million
and
I
expected
us
to
grow
at
a
1
million
per
month
or
something
and
now
we
have
15
million
findings
and
14.5
million
vulnerabilities.
So
it's
not
exactly
one-to-one
correspondence
because
not
every
finding
was
converted
into
a
vulnerability.
At
this
point.
B
But
I
mean
we're
not
creating
a
a
vulnerability
for
each,
not
yet
non-default
branch.
So
I
mean
that
those
numbers
line
up
that
it
would
that
it
would
be
a
default
branch
that
that
would
line
up.
B
Did
something
with
that
a
while
back,
I
have
to
see
if
I
can
find
it,
he,
he
mapped
out
all
the
the
data
structures
on
the
back
end.
I
don't
know
if
we
have
a.
We
had
an
issue
a
long
time
ago
to
actually
do
something
and
write
it
all
out
diagram
it
out
and
we
got
the
data
layer
diagrammed
out
and
it
is
a
spaghetti
code
like
diagram,
but
no
I,
that
is
something
that
we
need
to
do-
is
to
have
some
kind
of
flow
diagram
on
how
this
is.
It's
set
up.
F
And
then
probably,
I
think
it
would
be
useful
just
to
have
something
really
high
level
like
not
even
necessarily
going
down
to
that
data
layer
itself,
but
like
almost
like
a
decision
tree
like
if
non-default
branch
pipeline
like
what
happens
to
it,
you
know
where
does
it
get
read
from
that
kind
of
level?
Just
so
you
know
where
the
data
is
coming
from
yeah.
B
A
Well,
we
do
have
our
retrospective
in
10
minutes
and
I'm
pretty
sure
that
this
is
the
only
topic
on
it.
So
we
should
give
anyone
else
who
is
planning
on
joining
that,
but
not
this
discussion
the
opportunity
to
attend
that
is
there
anything
else
for
this
instance
of
this
meeting
that
anyone
wants
to
bring
up.
F
Okay,
I
had
one
thought
on
it:
if
nobody
else
has
anything
so
I've
seen
at
least
kind
of
on
the
product
side,
some
steps
in
a
direction
that
gitlab
traditionally
would
have
avoided
specifically
about
doing
things
that
don't
scale.
So
we've
made
a
change
to
the
handbook.
That
says
we
need
to
be
more
thoughtful
about
it
and
I
think,
there's
also
a
slight
softening
on
this.
F
You
know
micro
services
call
it
philosophy,
so
I
I
mentioned
this
to
thiago
a
week
or
two
ago,
and
I
didn't
really
want
to
bring
it
up
in
the
next
few
iterations.
Since
I
know
everybody
is
super
busy
with
fires
right
now,
but
this
idea
that
the
findings
and
vulnerabilities,
if
we
start
storing
everything
in
the
database,
is
going
to
grow.
It
apparently
a
geometric
rate
instead
of
a
linear
rate.
F
Would
it
make
sense
for
us
to
start
considering
breaking
off?
Basically,
the
secure
data
store
into
something
you
know
separate
much
like
we've
got
elasticsearch
backing
our
global
search,
because
I
am
kind
of
concerned
about
scalability.
We
want
people
to
use
this
more
and
more
and
more
and
more
and
if
that's
going
to
start
causing
problems
with
the
rest
to
get
lab.
Maybe
that's
something
we
consider
looking
at.
You
know
towards
the
back
after
this
year
and
then
working
on
it
next
year.
F
G
F
B
I
know
mimit
was
like
hey,
let's
use
cassandra.
D
D
All
right,
one
thing,
one
more
thing:
gentlemen:
I
found
an
issue:
that's
10
months
old,
created
by
thiago,
which.
A
D
Basically
me
saying
that
we
do
not
persist
things
that
are
not
in
the
default
branch
and
mehmet,
corrects
me
that
we
have
started
sorting
findings
for
all
branches
where.
G
D
D
So
that's
what
we
are
doing
and
I
am
trying
because
at
some
point
after
joining,
I
recall
myself
doing
a
database
diagram
of
things,
but
I
cannot
find
it
for.
I
have
no
idea
why
it's
somewhere,
but
it
might
be
in
a
different
project,
not
gitlab.org.org,
but
somewhere
else,
and
I
cannot
find
it
right
now,
so
it
might
show
up
on
the
agenda
later
on.
So
please
please,
please
check
it
check
check
it
out
later.
Yes,.
B
B
A
Two
things
I'll
try
and
share
this
video,
but
I've
also
been
attempting
to
take
notes,
and
you
guys
I
haven't
had
coffee,
I'm
half
awake,
please
correct
what
I've
said
and
I've
put
your
names
in
front
of
them.
So,
like
please
check
the
agenda
incorrectly,
I've
said
the
other
thing
is
that
up
until
very
recently,
I've
been
told
this
well
I'd
say.
Maybe
recently
I
thought
that
we
read
all
of
the
findings
from
the
analyzer
reports.
A
I
even
did
a
commit
presentation
where
I
misspoke
on
that.
So
thanks
for
all
this
knowledge,
I
appreciate
it.
I
wish
I
had
been
part
of
this
conversation
a
month
ago
or
two
and
we're
at
the
end
of
our
time
before
leaving
a
little
gap
between
retro.
So
I'm
gonna
hit
stop
on
the
recording
yeah.
I
totally
just
cut
you
off.
Did
you
have
something
else
that
you
wanted
to
add.
A
A
Please
share:
I
think
that
it's
the
beginning
of
what
we
need,
I
think
we're
gonna
need
some
some
better
and
some
more
recent
information.
I
hope,
if
you
did
this
that
long
ago,
maybe
we
haven't
changed
things
in
the
last
year.
Yeah
or
I
know
that
you
guys
are
in
the
process
of
dealing
with
some
some
debt
right
now.
So
a
future
vision
would
be
good,
too
cool.
I'm
gonna
not
just
leave
this
in
this
zoom
chat
link
as
well
thanks
mihawk.