►
From YouTube: Secure:Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights (previously Defend:Threat Insights) group
A
We've
had
a
few
conversations
recently
since
we
did
make
since
we've
launched
standalone
vulnerabilities
and
made
the
decision
to
use
graph
QL
at
building
the
dashboards
I.
Guess
a
question
came
up
just
in
discussion
between
myself
and
I.
Think
Alexander
of
whether
we're
still
supporting
all
of
the
same
rest,
endpoints
I
know
that
Thiago
and
I
have
closed
out
a
few
issues
recently
pointing
to
crack.
Ql
endpoints
dug
a
little
bit
deeper
into
this
I
guess
it
was
sorry
sabasha
it
out
of
this.
A
The
handbook
says
that
we
should
still
be
supporting
both
REST
API
and
grab
kale,
QL,
endpoints
and
I
know
I,
don't
see
any
back-end
faces
on
this
call,
but
my
question
is
really
by
some:
do
we
need
an
issue
to
create
rest
endpoints
for
things
that
we
have
built
graph,
QL
and
points
for
over
the
course
of
the
last
few
months?.
C
C
A
Question
I
just
know:
we've
closed
out
some
requests
recently
pointing
to
rescue
L
endpoint,
saying
hey.
We
got
this
covered
mmm-hmm,
hopefully
they're
listed
here,
if
not
I'm,
a
slacker,
yeah,
no
I'm,
a
total
slacker,
so
I
just
wanted
to
bring
that
topic
up
because
I
know
we
looked
at
breaking
changes
as
Friday
13
dead,
oh
and
we
looked
at
our
rest,
endpoints
then,
but
I'm
not
sure.
If
going
forward
and
new
things
that
we've
created,
if
we've
made
sure
that
we're
supporting
both
technologies.
B
B
C
C
A
You
know
we
got
there.
Okay,
the
second
item.
This
came
up
in
a
conversation
around
storing
findings
found
around
branches
versus
the
master
or
the
default
in
the
database,
and
we've
had
a
few
issues
related
to
this.
So
I
wanted
to
you
know
per
our
handbook.
Could
we
talk
about
something
synchronously?
A
If
you
know
a
handful
of
times,
we
should
bring
it
to
the
next
call,
so
I
added
it
to
the
agenda
and
I
think
it
actually
relates
to
one
of
the
items
that
when
the
Jonathan
had
added
to
the
planning
breakdown,
so
fortunately
don't
see
Jonathan
here
and
I,
don't
actually
know.
We
should
proceed
of
this
conversation
without
anyone
from
the
back
in
team,
Iago,
I'm
sure
that
you
have
opinions
and
I'll.
Let
you
share
them.
My.
C
A
Make
sense
to
me
you
know
I
know
there
was
a
totally
different
topic
that
Jonathan
was
talking
about
setting
up
an
asynchronous
call
with
EMEA
base
back-end
folks
for
a
minor
that
doesn't
help
you
Thiago,
but
I
think
maybe
we
need
to
think
about
as
a
way
to
get
everyone
on
the
same
page
about
some
of
these
bigger
items.
Yeah.
C
Look
have
most
of
the
people
in
the
backend
team
up
for
threading
sites,
not
know
a
lot
about
all
that
and
have
come
across
the
issue.
So
I
know
I
know
that
Mamet
is
well
aware
of
it.
So
is
Jonathan,
so
primarily
if
if
these
two
are
in
the
discussion
and
everybody,
everybody
else
can
catch
up
later.
B
So
I
have
been
working
on
this
third-party
list.
You
we're.
Basically
a
user
can
use
a
third-party
scanner
and
it'll
show
up
in
the
security
dashboard
now
I'll
have
the
scanner.
It
has
the
identifier
and
scanner
column
in
there
and
there's
been
some
discussion
recently
on
the
on
the
issue,
as
I
have
started,
to
implement
and
I
missed
some
things
during
playing
break
down,
and
that's
my
bad,
but
one
of
the
things
I
came
up
was
to
that.
B
The
group,
and
instance
level
security
dashboards
a
little
bit
busy
with
the
added
columns,
not
only
the
check
boxes,
they're
the
check
boxes,
and
then
this
is
playing
an
angle,
identifier
column,
then
the
scanner
type
column
and
with
the
graphs
off
to
the
side,
really
squishes
the
vulnerability
list
together
and
just
today,
I
was
talking
with
Andy
and
cam.
Thank
you
for
just
share
it
I.
Don't
know
why
I
didn't
share
the
screen.
This
is
a
lot
easier
to
look
at
obviously
anyways
this
conversation.
B
Basically,
these
these
columns
are
not
gonna,
go
on
the
group
and
instance
level
dashboard
at
this
time.
Until
those
vulnerabilities
over
time,
graphs
get
moved
off
and
then
the
group,
in
instance,
level
dashboards,
will
look
the
the
same
as
the
project
level
dashboard,
and
then
we
will
bring
the
columns
in
I
just
wanted
to
call
it
out
here
and
if
anybody
has
any
comments
on
that
or
questions
or
concerns,
the
the
one
concern
I
could
see
people.
B
A
A
B
A
One
of
the
things
that
I'm
concerned
about
is
that
you
had
to
read
through
a
lot
of
comments
to
figure
out
where
the
the
gotchas
were
in
this
issue.
Can
you
work
together
with
Andy
to
make
sure
that
the
description
gets
updated
to
reflect
not
just
this
decisions
but
others
and
Camellia
as
well
other
decisions
that
have
made
through
the
course
of
the
last
Oh
three
months?
Wow.
That's
a
baby
issue.
A
A
Hey
yeah
I
drew
carrots
all
over
the
place
today,
but
my
carrots
were
super
lonely.
We
talked
about
this
in
the
staff
meeting.
I
know
not
everyone
is
always
able
to
make
it
to
the
staff
meeting.
One
of
the
things
that
we
discussed
was
making
sure
that
we're
kind
of
holding
people
accountable
for
looking
at
issues
ahead
of
time
going
into
planning
break
down
I
think
we
use
our
time
a
lot
better.
A
If
people
spend
I
mean
I
literally
spent
15
minutes,
while
I
was
one
hand
eating
eating
my
lunch,
putting
carrots
on
things
and
reading.
So
if
folks,
as
a
reminder,
can
try
and
take
a
little
bit
of
time
ahead
of
this
meeting
to
go
and
pre
review
the
issues
that
are
at
least
listed
for
planning
break
down
again,
I
don't
expect
people
to
look
at
the
whole
entire
agenda
and
go
through
everything,
but
at
the
very
least,
focus
on.
C
A
A
A
A
D
A
D
It's
it's
not
right
away,
there's
at
most
a
six
second
delay,
but
you'll
get
it
eventually.
A
Except
that
okay
and
then
we
have
a
huge
list
or
funding
breakdown
today,
so
I've
been
trying
to
go
through
and
add
a
little
bit
more
information
to
the
agenda
to
tell
people
sort
of
the
urgency
or
the
priority
as
far
as
where
things
are
classified
so
I've
been
adding
these,
whether
it's
a
bug
or
a
feature
or
backstage
and
then
where
it's
sitting.
So
the
first
item
is.
A
E
Think
there's
one
unique
thing
about
secrets
for
this
issue:
is
that
secrets
through
secret
detection,
so
I
noticed
if
you
scroll
down
and
this
particular
issue,
the
identifier
was
like
truffle,
hog
or
yeah,
so
secrets
may
not
appear
in
the
default
branch,
but
we
are
parsing
those
historically
and
almost
doing
that
branch
storage
of
secrets,
because
we
have
a
historical
secret
scan
so
by
the
nature
of
a
secret,
though
it
appears
bad,
it's
not
currently
stored
in
the
branch.
So
that's
probably
why
we're
seeing
a
lot
of
this?
Hey?
It's
not
in
the
master
branch.
A
E
A
Could
you
add
it
as
a
comment
to
this
issue
Andy
just
for
transparency,
sure,
thanks
and
I'm
guessing
we
should
leave
this
on
the
agenda
for
future
I'm,
still
sort
of
on
the
fence
around
bugs
in
planning
break
down.
You
know
whether
we
actually
really
should
discuss
bugs
and
planning
break
down.
I've
been
a
little
subjective
about
it.
Yeah
I,
don't
know
you
have
opinions,
but
this
is
probably
a
good
example
of
one
that
could
be
handled
during
just
by
going
straight
to
refinement
so.
C
A
C
A
C
A
That
was
one
of
the
factors
that
made
me
bring
it
to
this
all,
because
I
was
really
sure
hey
to
send
it
to
triage
it.
Do
you
someone
just
gonna,
add
a
note:
do
that
let's
move
on
to
the
next
one,
so
Bosch
isn't
here,
so
we've
been
making
progress
on
we
removed
the
first
class
vulnerabilities
feature
flag.
A
C
B
A
So
think
my
real
thumb
is
a
lot
easier
than
trying
to
find
the
reactions
thing
and
zoom
and
adding
the
thumbs
up.
So
my
question
out
to
Daniel
and
Alexander
since
Abbas
created
this
issue.
Do
you
feel
that
this
meets
all
of
our
criteria
for
planning
breakdown?
I
have
already
moved
to
ready
for
them,
but
he
did
lifts
it
here.
So
I
wanted
to
double-check
with
you
guys
whether
it's
we
understand
their
boundaries,
the
requirements
clear
and
if
it's
something
we
think
we
can
accomplish
within
a
iteration
I
think
are
three.
D
A
C
D
C
A
I
think
Daniels
question
was
similar
to
mine
earlier.
Is
that
that
was
about
removing
the
flag
and
making
sure
that
the
flag
doesn't
drive
the
experience.
You
know
if
there's
any
additional
code
cleanup
that
needs
to
be
done,
whether
it's
based
on
you
know
how
the
findings
worked
or
anything
like
that.
I.
C
Think
I
think
there
is,
but
but
I'm
not
sure
if
it's
just
from
the
end
of
this
back
end.
B
C
C
A
Not
totally
satisfied,
but
it's
something
because
I
don't
I
spent
a
lot
of
time,
trying
to
understand
the
difference
between
findings
and
vulnerabilities,
and
then
people
throw
around
the
word
occurrences
and
I
get
really
like.
You
know
twitchy
again
and
I
know.
This
has
come
up
as
part
of
our
retrospective
feedback.
So
I'm
gonna
table
this
right
now.
But
this
idea
of
having
maybe
like
a
workshop
around
sort
of
some
of
the
historical
domain,
knowledge
or
findings
and
occurrences
and
vulnerability.
A
E
And
I
are
actually
working
on
some
research
initiatives
to
understand
Boehner
built
like
unique
vulnerabilities
and
how
they
work
in
vulnerability,
management
and
enterprise
as
like
occurrences
or
instances
of
so
I.
Think
it's
confusing
because
it's
confusing
and
we're
also
like
still
kind
of
building
it.
E
D
C
Sure,
once
that
that
issue
was
a
was
a
bit
large
and
we
we
figure
was
gonna,
take
a
few,
maybe
not
a
few,
but
more
than
one
iterations
complete
with
several
issues
back
in
from
ten
I
created
an
epic,
a
container
epic
that
one
thank
you
and
as
part
of
planning,
Baker
breakdown,
Avast
you
and
the
backend
engineers
to
to
suggest
what
what
the
issues
should
be.
So
Mamet
gave
me
a
list
of
four
issues
that
he
he
suggested.
C
I
thought
they
were
good,
I
put
them
in
there
he's
already
out
of
the
weight
for
most
of
them.
There's
one
of
them
is
pending
a
decision
around
whether
we
need
two
mutations
for
the
state
or
just
one,
because
apparently
there
are
some
background
tasks
around
feedback
when
the
state
changes,
but
not
for
other
fields,
change.
So
there's
a
there's,
a
discussion
on
whether
you
need
a
separate
on
for
that
and
I'm
how
we
do
the
same
with
front-end,
so
you've
answered
my
my
question
as
well.
A
So,
just
to
be
clear,
this
design
issue
is
gonna,
reflect
the
plan
and
the
requirements
and
overall
what
we
need
to
do
as
an
engineering
organization
to
support
these
end
points
in
graph
QL,
which
I
know
Daniel.
This
is
a
little
bit
I,
don't
think.
We've
done
a
great
job
of
explaining
that's
across
the
whole
engineering
organization,
so
you
probably
created
those
thinking
that
it
was
going
to
end
up
being
sort
of
the
implementation
issue.
A
This
is
kind
of
our
evolution,
of
trying
to
be
able
to
break
things
down
into
separate
fronts
and
back-end
issues
having
something
on
the
issue
boards
that
reflect
that
progress
of
planning
to
get
it
to
the
build
point
of
like
okay.
Now
we're
ready
to
break
this
down
and
create
those
implementation
issues,
ethics
are
limited
in
their
functionality,
so
we're
using
this
as
a
design
issue
to
get
to
gain
all
of
those
requirements.
C
And
Lindsay
want
one
more
thing
that
this
is
trying
to
solve.
Is
that
the
confusion
when
you
have
to
go
through
a
long
history
of
threads
and
discussions
all
right?
So
what
did
we
agree
again
with
this
approach?
You
sort
of
take
away
just
okay.
This
is
what
was
agreed,
and
this
is
this
is
the
final
requirement
and
then
that's
on
the
implementation
issue.
A
Conversation,
we
hope
will
happen
here
in
the
design
issue
and
then
the
output
of
those
conversations
will
be
what
is
used
to
feed
the
issue
description
for
those
implementation
issues.
You
want
to
avoid
all
the
scrolling
through
comments
that
we
talked
about
earlier,
to
figure
out
what
the
requirements
actually
are
and.
C
B
Just
want
I
remember,
as
I
mentioned
in
this
comment,
that
back
when
we
were
gonna
remove
the
Hamel
from
the
standalone
blown
into
the
page.
It
was
deeper
ties
with
the
reason
of
like
no
more
features
are
coming
to
this
page
like
it's
gonna,
be
kind
of
like
static
for
a
while,
and
you
know
now
that
we've
done
that
and
now
there's
this
ticket
I
was
just
kind
of
curious.
What
the
future
future
looks
like
for
this
page
and.
E
That's
the
vulnerability,
details,
page
right,
correct
it
looks
bright
in
bushy
and
it's
it's
gonna
have.
It
will
be
one
of
the
driving
forces
that
makes
vulnerability
management.
Important,
oh
and
usability
lab
and
we'll
be
working
with
the
monitor
team
who's
implemented
alerts
to
hopefully
create
a
like
synchronous
design
that
we
can
kind
of
borrow
each
other's
work,
the
Monterey
hillside,
because
they
have
like
first-class
or
standalone
alerts
or
incidences
as
well.
But
it
will
be
very
important
to
us.
Okay,
so
there's
a
lot
coming
down
the
pipeline,
then
correct
yeah.
E
B
A
D
I
think
we
can
do
it
piecemeal
where
once
the
back
and
end
point
is
in
place,
we
can
convert
the
front
end
part
of
the
code
that
uses
the
graph
or
that
that
would
use
the
graphical
endpoint
and
the
reason
is
because
the
rest
endpoints
aren't
going
anywhere
and
if
the
graph
kill
four
other
end
points
is
in
yet
we
can
still
use
the
rest
endpoint.
So
we
I
don't
think
we
necessarily
need
to
have
a
feature
flag.
We
could
just
convert.
What's
what
end
points
are
available.