►
Description
Weekly meeting for the Secure:Threat Insights group
A
A
I
added
a
follow-up,
so
this
was
an
item
that
we
were
looking
at
for
planning
breakdown
last
week
and
I
kind
of
just
moved
it
up
into
the
discussion
area.
You
know
given
that
thiago
and
neil
aren't
here
right
now.
I
know
that
you
know
thiago's
created
an
epic
and
started
to
think
about
how
we're
going
to
take
this
poc
that
james
has
created
and
break
it
down
and
start
to
make
it
production
ready
and
integrate
it
into
our
code.
A
I've
been
talking
to
neil
a
little
bit
about
his
front
end
group
and
secured
taking
some
amount
of
that
work,
since
it's
a
it's
a
big
blocker
for
things
like
them,
displaying
the
fuzz
testing
results.
I
think
that's
the
first
immediate
benefit
that
we
get
from
that
generic
schema.
That
would
allow
us
to
style
things
on
the
vulnerability
details
page,
but
I
didn't
want
to
leave
this
conversation
kind
of
hanging
from
last
week.
A
So
alexander,
I
don't
know
if
you've
had
a
chance.
I
know
you've
been
really
busy
looking
at
other
things,
and
we
don't
have
my
met
here,
but
when
we
talked
last
week,
the
two
of
you
are
going
to
take
a
look
at
this
from
a
front
end
and
back
in
perspective
and
ask
some
questions
and
to
kind
of
provide
your
feedback
on
how
you
thought
it
would
make
sense
to
approach
this
integration.
Do
you
have
any
thoughts
on
it.
A
And
I
think
it's
probably
like
I
said
I
think,
that's
okay,
given
what
I
just
said
and
the
preface
of
we're
still
sort
of
trying
to
figure
out
from
a
high
level.
You
know
matt,
I'm
also
still
unclear
from
you
around
priority
in
regards
to
some
of
the
other
items
that
we
have
upcoming
with
the
mr
widget,
and
you
know
some
of
the
other
things
that
we
were
looking
at
that
are
in
design.
So
I'm
not
trying
to
ask
you
to
answer
that
right
now,
but
I
think
that's,
I
think,
we're
a
little.
A
This
is
a
weird
one,
because
planning
breakdown
on
a
poc
is
different
than
planning
breakdown
on
a
design
issue
or
a
new
feature
request,
and
we've
never
quite
been
through
this.
So
we
don't
have
a
set
of
instructions
to
follow
here.
So
I
think
we're
kind
of
putting
that
together
as
we
go
right
now,.
C
C
So
I
would
say
that
this
is
very
much
in
line
with
that.
It's
not
quite
originally
where
that
was
targeted,
but
that
was
a
terrible
way
to
say.
I
would
consider
this
part
of
an
existing
plan
on
the
the
roadmap
piece.
So
that's
where
this
would
go,
and
I
would
see
this
kind
of
extending
through
the
end
of
the
year.
C
A
The
thing
that
I
keep
getting
hung
up
on
and
what
you
just
said
reminded
me
of
that
is
that
poc
really
encapsulates
two
big
areas
of
improvements.
One
is
what
I
think:
matt
was
speaking
directly
to
just
now,
which
is
the
fingerprinting
so
looking
at
whether
this
is
something
we've
already
seen
before,
if
it's
new
or
if
it's
been
moved,
or
you
know
some
of
those
improvements
around
the
data
and
then
the
second
big
piece
is
taking
sort
of
a
dynamic
js
or
a
a
generic
json
scan
result
and
formatting.
A
It
formatting
the
the
data
associated
with
that
in
the
vulnerability
detail
page
in
such
a
way
that
we
can,
you
know,
put
it
on
the
scanner
owners
to
be
able
to
dictate
what
that
looks
like.
So
I
yeah.
So
I
will
take
some
time,
and
maybe
this
is
something
that
we
don't
bring
back
to
this
agenda
until
we
have
a
better
plan,
but
I
don't
want
people
to
lose
sight
of
it.
So
any
other.
D
C
C
But
yes,
that's
the
front.
End
piece
is
rendering
things
like
urls
or
a
diff
block,
or
even
having
you
know,
get
lab
flavored
marked
down
as
a
content
type
for
a
field
so
that
we're
just
sort
of
pasting
those
in
order
on
the
screen
and
not
having
to
do
scanner
specific
logic
when
they
start
wanting
to
add
some
of
these
more
complex
output.
A
A
I
know
we
have
done
design
issues
that
are
not
like
ux
design
issues,
but
like
technical
solution,
design
issues.
I
think
we
should
talk
to
thiago
about
that,
so,
but
something
that
represents
each
one
of
these
two
sides
of
this
poc
that
we
can
put
into
our
regular
process
would
definitely
make
this
easier
to
move
forward
with.
D
A
D
A
E
Okay,
so
just
one
of
the
issues
that
came
out
of
dog
fooding,
it's
great
we're
finding
issues
via
dog
food,
because
that
means
dog
food
is
working.
We're
really
trying
to
use
things.
It
was
just
this
deduplication
issue,
just
as
we
think
about
the
report
scheme
to
think
about
how
we
can
make
it
possible
and,
if
possible,
easy
to
de-duplicate
results
and
not
recreate
the
same
result
multiple
times
in
different
ways,
either
in
the
same
scan
or
across
different
scans.
So
just
something
to
keep
in
mind.
It's
more
tangential.
A
Cool
thanks,
andy's
been
busy
crafting
design
issues.
This
is
an
early
look,
so
I
didn't
put
it
in
planning
breakdown
and
I
don't
know
if
anyone's
actually
had
a
chance
to
look
at
it
very
much
because
I
just
added
this
to
the
agenda
yesterday.
I
think
andy
just
brought
this
to
our
attention
yesterday.
So
this
is
a
design
issue
around
manually,
creating
vulnerabilities,
and
I
wanted
to
make
sure
that
we
got
feedback
to
andy
early
on
andy.
How
close
are
you
to
planning
breakdown
for
this?
D
I
think
a
lot
of
comments
have
started
trickling
in
from
the
appsec
team.
They
ping
them
in
slack
to
give
this
a
look
over,
but
I
think
everyone,
if
you
can
have
time,
just
give
it
a
look
again
and
throw
comments
in.
I
think
where
I
would
like
to
have
this
done
by
the
end
of
the
milestone
kind
of,
or
at
least
like
before,
kickoff,
usually
like,
maybe
even
up
to
a
day
before
the
next
kickoff
so
probably
a
week.
A
A
F
A
F
So
I
just
overlooked
it.
I
didn't
see
that
the
solution
parts
was
different,
so
the
I
had
to
restyle
that
part
as
well
so
create
an
another.
Mr
for
that,
and
also
the
the
result
button.
I
also
created
nmr
for
that
today.
It's
it
has
a
different
background.
Now
I
think
I
assigned
andy
for
review
for
both
of
them
so
yeah,
that's
the
update
and
thanks
alexander
for
jumping
in.
A
A
I'd
say
before
it
goes
to
review
so
that
if
he
has
any
feedback,
we're
not
asking
people
to
re-review
okay,
and
we
have
one
issue
for
planning
breakdown
today,
which
is
bringing
the
group
and
instance
reports
in
line
with
what
we
have
for
the
project
level.
So
adding
these
severity
counters
at
the
top
of
the
vulnerability
list.
Page,
not
the
dashboard.
A
A
A
A
A
So
it'd
be
a
refinement
question,
but
I
don't
know
if
we
need
to
create
a
front-end
and
back-end
issue
to
refine,
so
we're
kind
of
in
that
place
where,
with
this
one,
if
we're
doing
planning
breakdown,
it'd
be
great
to
be
able
to
just
decide
what
the
breakdown
is.
Do
we
need
more
than
one
issue
for
this
if
there's
back
end
work
that
would
imply
that
there
would
be.
G
A
F
A
Bit
so
it
sounds
like
based
on
what
you're
saying
it's
small
enough
to
fit
into
one
iteration
yeah.
Okay,
probably
it
sounds
like
by
all
measures.
This
issue
has
passed
planning
breakdown,
we'll
move
it
into
refinement.
Based
on
what
savas
just
said,
it
needs
a
back
end
issue.
I
can
take
the
action
of
getting
that
created
and
we're
good.
E
H
I
don't
know
that
I
have
any
recommendation
at
this
point,
I'm
here
to
observe
and
learn
and
just
see
how
how
discussion
and
collaboration
happens
and
so
far
I'm
really
impressed
lindsay
you're
in
charge
in
terms
of
making
sure
people
speak
up,
and
I
love
that.
I
see
that
there
was
a
portion
of
the
meeting
dedicated
to
the
demo
and
honestly
I
missed
that.
One
thing
that
you
know
I'm
seeing
is
there
was
some
discussion
about
front-end
back-end,
I'd
love
to
see
front-end
and
back-end
on
the
same
call.