►
Description
Agenda: https://docs.google.com/document/d/1OoBhaX2sRcLAndm7B2ENUTi5f6OGaQfAcBN1Rv1Bukw
A
Good
day,
everyone
this
is
the
security
threat,
insights,
weekly
group
discussion
on
october,
the
12th
or
13th.
If
you're
in
australia
on
that
side
of
the
meridian
and
and
jonathan,
was
talking
about
a
long-standing
issue.
We
skipped
planning
breakdown,
a
that's
about
disabling
the
surveyor
on
kano
and
we
skipped
into
vulnerabilities
graph
graph
key.
Well,
not
graphical
query
does
not
return
vulnerabilities,
so
jonathan,
take
it
away.
Where
were
we.
B
All
right,
so
we
have
so
there's
this
issue.
That
is
in
the
notes
here
I
had
started
because
the
vulnerabilities
query
only
pulled
vulnerabilities
from
the
instant
security
dashboard
which,
if
you
like,
makes
a
valid
point
saying
if
you
actually
read
the
documentation,
that's
what
it
says
it
does,
but
it's
just
kind
of
strange
that
a
global
vulnerabilities
call
only
pulls
from
a
certain
group,
and
so
we
down
lower
we're
talking
about
adding
the
capability.
B
In
the
instance,
security
dashboard
call
to
pull
the
vulnerabilities
for
that
for
the
instance
security
dashboard.
We
already
have
group,
we
already
have
project,
so
we
were
talking
about
moving
the
vulnerabilities
to
the
dashboard
call
and
deprecating
the
actual
vulnerabilities
call-
and
that's
actually
suggested
by
savas
in
a
similar
issue
where
he
was
suggesting
group
project
instance
and
pipeline
vulnerabilities
being
the
same
call.
But
we
can't
really
it's
the
pipeline.
One
is
different
because
that's
security
findings
and
they
get
pulled
a
little
bit
differently
than
the
vulnerabilities
themselves.
B
This
this
one
here
yeah.
So
I
don't
think
we
ever
quite
decided
on
that
one
but
yeah.
So
you
have
grouped
up
vulnerabilities
project
vulnerabilities
and
then
just
like
the
top
level
vulnerabilities.
B
B
End
I'd
like
we'd
like
it,
if
that,
if
that's
gonna,
suffice
for
that
second
issue,
I'm
actually
probably
going
to
close
this
issue
and
just.
A
B
It's
better
explained,
the
discussion
is
kind
of
my
like
morphed
into
what
the
second
issue
would
be
more
likely
just
aligning
all
of
our
graphql
vulnerabilities
calls.
So
maybe.
C
So
it
is
so.
We
are
now
concerned
about
like
whether
this
these
link
a
call
is
used
in
anywhere
in
the
front
end
or
not.
That's
why.
B
B
Just
kind
of
looking
at
the
second
here
I
think
we
wanted
the
group,
so
we
have
group
project
group
and
instance,
security,
dashboard
and
getting
rid
of
the
top-level
vulnerabilities
to
kind
of
clear
out
any
kind
of
misunderstanding
confusion
about
what
it
should
be
pulling
or
what
it
should
not
be
pulling.
B
It's
a
little
bit
different.
What
savash
is
recommending
is
using
that
top
level
vulnerabilities
call
there
to
have
a
security
center
flag,
which
is
actually
something
I
had
suggested
in
the
other
one
but
being
able
to
put
project
id
in
group
id,
and
it
would
remove
the
constraint
of
the
vulnerability,
the
top
level
vulnerabilities
call
being
only,
for
instance,
security
center.
C
B
B
It's
it.
I
guess
to
me
it
is
kind
of
weird
to
have
a
top
top-level
vulnerabilities
call,
because
a
vulnerability
has
to
belong
to
something
you
know
it's.
These
vulnerabilities
belong
to
this
group.
These
vulnerabilities
belong
to
this
project.
These
vulnerabilities
belong
to
this
instant
security
center.
You
don't
only
just
like
pull.
A
B
That
is
part
of
it
that
we
do
need
to
limit.
How
many?
How
many
I
mean
it's
the
same
thing
for
the
group
vulnerabilities
and
these
instant
security,
where
you
just
pull
a
ton
of
vulnerabilities
at
one
time
and
it
can
kind
of
overload
the
the
database
query.
The
same
reason
why
we
get
some
of
these
500s.
B
Every
project
yeah,
so
so
one
of
the
restrictions
on
this
calls
it
would
have
to
have
one
of
the
flags
either
group
project-
or
you
know-
is
security
center.
It
would
have
to
have
one
of
them,
otherwise,
it'd
be
an
invalid
call,
because
otherwise
you're
pulling
all
the
vulnerabilities
you
can
see
in
every
project
which
no
one
should
be
doing.
That.
B
I
mean
that's,
that's
pulling
a
bunch
of
vulnerabilities
at
one
time
and
that
would
be
trying
to
and
trying
to
sort
at
all
through
like
the
severity.
A
A
B
Fair
enough
yeah,
so
just
just
you
know,
hammering
out
the
the
final
path
forward
on
this
thing
was
the
main
point
in
trying
to
bring
this
up
getting
the
front
end,
what
they
wanted
out
of
it
as
well,
because
they
want
they
want
a
single
call.
That's
that's
that's
what
they
when
they
want
to
be
able
to
have
a
single
call
to
limit
how
many
different
places
they're
trying
to
call
this
thing.
A
Yeah,
there's
a
there's,
a
there's,
a
bit
of
complexity.
If
I
understand
it,
there's
a
big
complexion
on
the
front
end
due
to
that
they
gotta,
you
know
basically
stitch
together,
different
query
fragments
in
order
to
use
these
different
things
and
they
see
an
opportunity
to
just
this
could
be
the
same
yeah,
but
it
needs
to
work
on
the
back
end.
I
think
I
think
the
ball
is
in
our
court
on
this
one
yeah.
Sadly,
it's
not
very
high
in
in
our
priorities
right.
We
currently
working
on
the
stability
issues.
A
All
of
you
have
enough
on
their
plates.
A
B
Am
I
oversimplifying
this?
No,
I
don't
think
so.
I
think
it
we
just
it
is
we
just
have
to
make
a
decision.
It's
like
this
is
the
proposal.
This
is
how
we
should
go
and
I'm
willing
to
go
ahead
and
do
that,
go
ahead
and
put
a
proposal
out
there
on
this
issue.
Saying
hey:
let's,
let's
do
this
proposal,
I'm
not.
A
Wow
I
I
had
to
buy
one
of
these.
A
B
No,
what
you
got
there
now
is,
you
know
you
can
run
some
tests
and
then
you
can
cook
some
eggs.
You
know
look
like.
I
got
a
little
like
griddle.
B
That
was
the
other
thing
that
we
decided
is
that
we're
going
to
start
calling
postgres
post-grad
school
yeah,
that
was
that
was
thiago's.
We.
A
Have
an
issue
we
have
an
issue
for
that,
the
proposal
I'll
stop
recording.
I
think
I
think
we
we
reached
the
end
of
the
we
have
reached.