►
From YouTube: Secure:Threat Insights - Group discussion 2020-09-15
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).
A
Thank
you.
Thank
you
wayne.
I
totally
forgot.
First
thing
is
to
look
at
all
the
accomplishments
that
us,
as
a
team,
have
done.
There
are
many
of
them
26,
plus
that's
very
exciting.
Congratulations!
Everyone
keep
up
the
good
work
that
is.
B
B
A
C
B
That
met
the
hackathon.
There
was
a
community
hackathon
recently
across
get
lab,
plus
the
outreach
that
we've
been
doing
to
the
community
contributors.
The
the
the
thing
that
you
organized
tiago,
I
think,
helped
a
lot
as.
A
A
Tuned
previous
discussions
lindsay,
who
is
not
present,
had
a
discussion
about
sorting
columns
and
security
dashboard
initial
implementation
issue
only
covered
sorting
by
severity,
but
then
another
issue
captures
the
omid
scope
of
the
rest
of
them.
A
Do
we
need?
Does
this
need
to
go
through
playing
breakdown?
C
A
Yeah,
that's
a
great
point,
there's
like
add
complexity.
If
there's
more
than
one
column
being
sorted
on
like
what
takes
precedence.
D
I
think
for
now
we're
just
gonna
do
whatever
column
you
clicked
last
is
what
gets
the
sort
we're
not
going
to
do
like
a
secondary
level,
sorting
that
is
desired
by
folks,
but
I
would
consider
that
an
extra
above
and
beyond
feature
plus,
I
don't
know
how
they
would
look
in
the
ui.
I
don't
think
andy
that
your
designs
had
that
in
there
so.
A
D
E
E
A
Then
yeah,
I
think
I
think,
as
long
as
we
capture
those
details,
everything
that
we've
just
talked
about,
then
I
don't,
I
think
that
was
playing
breakdown
and
then
the
rest
can
be
handled
in
refinement.
A
Cool
and
people
are
updating
their
conversations
there
on
the
dock.
Thank
you
so
much.
We
have
some
demos.
Savage
updates
fairy
accounts
to
match,
apply
filters
right
so
on
the
project
level.
Security
dashboard.
Now,
when
you
filter
the
accounts
at
the
top,
are
updated,
which
is
great.
That
was
confusing
a
lot
of
people.
Thank
you.
Savage.
A
F
A
Question,
well,
I
guess
savash
isn't
here,
so
it
doesn't
matter,
but
that's.
Okay,.
B
So
just
a
question:
it
looks
like
great
stuff
have
we
are?
We
have
we
also
updated
the
documentation.
A
That's
a
great
joke.
Swash
also
added
detected
column
to
the
vulnerability
list,
which
is
excellent
and
I
believe
that
probably
has
gone
and
that's
on
the
project.
Security
dashboard
might
be
on
the
other
dashboards
stay
tuned
and
then
that's
possible
because,
oh
actually,
it
is
because
in
the
very
next
thing
I
posted
that.
A
D
Yeah,
I
wanted
to
point
out
on
that
one.
So
if
you
haven't
seen
it,
it's
not
really
something
that
we're
the
team
used
to
track,
but
the
apsec
team,
with
philippe
self
have
compiled
sort
of
their
must
have,
should
have
nice
to
have
lists
of
things
and
making
sure
that
there's
an
issue
against
them.
That
was
like
their
number.
One
thing
on
their
must-have
list
is
getting
that
detected
date
so
that
they
can
sort
by
that.
So
that's
huge,
especially
since
it's
going
to
be
across
all
the
dashboards.
D
D
A
Yeah
outside
of
mine
for
sure
cool
does
someone
want
to
take
over
for
the
playing
breakdown
section.
B
F
Okay,
so
the
first
one
is:
allow
reverting
a
vulnerability
back
to
detected
state.
It's
already
in
review,
don't
think,
there's
much
that
needs
to
be
said
for
this.
One.
D
A
Yeah,
I
think
the
discussion
last
time
ended
on
discussion
around
iteration
and
I
think
it
was
a
good
someone
made
a
good
point
if
we
can
go
back
and
watch
the
video
about
how
this
is
a.
It
is
a
more
the
mr
state
or
view
is
a
more
mature
state,
and
so
we
need
to
be
more
careful
on
how
we
iterate.
I
think,
there's
been
several
instances
where
we've
iterated
on
some
of
our
features
where,
like
the
user
sees
there's
like
two
opt
two
vulnerability
reports
for
a
project.
A
That
happened
at
one
point,
and
it
was
a
good
point
to
make
that
we
can't
do
that
here
and
I
think
that's
where
it
ended.
F
Okay,
so
moving
to
the
next
one
hide
create
issue
button
on
vulnerability
page
if
a
customer
does
not
have
issue
tracking
so
same
thing,
lindsey
asks
if
more
discussion
is
needed
for
this
one.
F
It's
it
seems
like
it's
pretty
straightforward.
If
you
don't
have
an
issue
board
enabled
for
the
project,
then
the
create
issue
button.
It
should
not
be
shown.
F
I
I
only
have
one
question
about:
should
we
show
related
issues
altogether
if
they
don't
have
issue
tracking,
should
we
just
hide
the
create
issue
button
but
still
show
the
related
issues
panel.
D
C
Okay,
doesn't
when
we
have
the
the
what
is
it
called
the
reference
character?
Doesn't
that
automatically
populate
that
as
well?
Does
it
automatically
create
a
reference
if
you,
if
you
use
the
carrot
and
the
id
of
the.
D
Yes
and
then,
of
course,
you
can
only
reference
an
existing
issue,
so
by
definition,
if
you
can
reference
it,
it
exists,
which
means
you
should
be
able
to
show
it.
I
think
this
one
is
just
making
net
new
issues
inside
of
a
project
where
issue
tracking
is
turned
off
like
it's
to
be
clear.
It's
making
an
error
today,
because
it's
saying
I'm
guessing
behind
the
scenes.
It's
like
no,
I
can't
do
that.
There's
there's
nothing
turned
on,
so
we
just
need
to
hide
the
button.
C
F
Not
in
the
not
for
related
issues,
you
have
to
manually
actually
link
them.
Yeah
like
it's
not
the
same
as
the
other
ones,
where
you
can
in
another
issue,
add
a
reference
to
this,
we're
actually
adding
that
we're
adding
the
ability
to.
I
just
remembered
that
allen
has
a
some
mrs
up
to
be
able
to
add,
there's
going
to
be
a
carrot
symbol
now
that
you
can
use
to
link
to
a
vulnerability
yeah.
F
Asking
oh
okay,
yeah,
I'm
not
sure
how
that's
going
to
work.
I
did
have
a
cursory
look
at
the
mrt
had
opened,
but
I
didn't
see
anything
in
there.
It
seems
like
he's,
adding
the
functionality
to
the
autocomplete,
but
it
hasn't
been
decided.
Yet
what
we're
going
to
do
once
that
functionality
is
it
like?
Should
we
do?
We
show
like
a
history
entry
to
this.
Do
we
show
related?
F
F
D
So
alexander,
I
saw
you
had
a
comment
on
that
issue
and
I
just
left
you
one
right
before
the
meeting
on
that,
but
I'll
go
ahead
and
reiterate
it
here.
So
for
that
for
the
defect,
you
don't
need
to
worry
about
the
third
party
issue
tracking
at
all
digging
into
that
get
lab
issues
totally
separate
from
third-party
issue
tracking
and
the
behaviors
don't
seem
to
overlap
so
just
push
that
one
out
of
your
mind
and
we'll
we'll
handle
that
separately.
If
we
need
to.
A
D
A
Excellent
cool
yeah
and
that
and
that,
because
you've
left
that
that
I
I
pushed
it
too
ray
for
development,
because
because
I
refined
it.
C
A
I
forgot
that
I
had
don't
add
that
in
the
implementation
plan
I
will
update
that
immediately
after
this
meeting.
D
All
right,
this
is
a
big
one,
I'll
start
by
asking
his
anyone,
or
hopefully
everyone
had
a
chance
to
look
at
the
brown
bag
session
that
james
johnson
did
a
couple
of
weeks
ago,
all
right
fantastic.
D
That
will
help
us
greatly.
Since
we've
got,
I
think,
there's
six
different
common
formats,
one
for
each
of
the
scanner
teams,
it's
a
real
hassle
for
versioning
for
the
scanner
teams
as
well
as
for
us
whenever
they
try
to
add
a
new
field
if
they
want
it
displayed
in
a
particular
way,
whatever
we
have
to
add
logic
inside
the
vulnerability
management
component,
so
I
think
it's
going
to
be
primarily
back-end
until
we're
ready
to
start
doing
things
with
it
on
the
front
end.
D
But
I
think
the
first
step
is
supporting
parsing
his
proposed
generic
format
and
then
ultimately
moving
towards
using
the
definitions
of
those
fields
and
using
that
for
rendering
the
generic
components
in
the
ui
so
that
we're
not
having
to
do
a
specific
scanner
specific
rendering
rules.
I
guess
in
the
front
end
it
will
all
be
predefined,
which
would
be
pretty
slick.
So
I
don't
even
know
how
to
eat
this
elephant
thiago.
You
want
to
step
in
here
because
there's
just
like
a
bunch
of
mrs
and
it's
all
very
weedsy.
C
But
if,
if
if
it's
been
proposed
and
we're
gonna
own
it,
we
we
we
need
to
review
it
and
make
sure
we're
happy
to
to
maintain
it
and
that's
not
gonna
cause
any
for
the
problem.
So
the
way
I
I
I'm
thinking
about
it
is:
it's
got
three
main
sort
of
disciplines
to
it
or
groups
that
that
need
to
work.
One
is
the
json
schema
itself,
so
that's
the
that's.
The
format
of
the
report
that
the
analyzer
generates
that
sort
of
sits
with
the
other
groups.
C
Although
we
we
need
to
be
across
it,
because
the
next
step
is
once
there's
a
report,
a
json
report.
We
need
to
ingest
that
and
the
way
that
gets
ingested
is
there's
a
parser
which
we
in
threatening
sites
are
responsible
for
and
that
parser
will
try
what
one
the,
when
the
merge
request
is
merged
to
the
to
the
default
range.
C
That
information
goes
into
the
database,
which
means
we
also
need
to
create
the
database
fields
for
it,
so
that
that's
two
groups
and
then
the
third
one
is
the
front-end.
So
now
that
we
have
this
information
in
the
database,
we
need
to
render
it
on
that
stand-alone
vulnerability
on
the
on
in
there,
and
I
my
so
in
terms
of
actions.
C
What
I
was
thinking
is
that
front-end
and
back-end
could
review
the
dmrs
and
and
suggest
an
approach
to
say
you
know,
break
this
down
refactor
that
have
some
questions
on
this
and
then
almost
like
reverse
engineer
the
feature
into
requirements.
So
we
can
push
it
through
the
the
meat
grinder
and
see
what
comes
out
of
the
other
one
make
make
some
sausages.
D
One
thing
I
do
want
to
add
is
because
this
is
a
proof
of
concept.
It's
a
very
functional
one,
but
there
are
some
things
we
may
want
to.
I
guess
I
want
eyes
on
it
from
a
large
scale,
production
ready
standpoint.
So
one
of
the
things
that
james
has
done,
which
is
super
awesome,
is
it's
a
recursive
structure,
so
you
can
sort
of
nest
as
far
as
you
want.
I
don't
know
if
we
want
to
allow
that
to
be
an
unbounded,
recursion
depth
things
like
that.
D
So
if
we
want
to
start
putting
enforcement
parameters
in
certain
places,
these
are
the
kinds
of
things
that
we
should
look
for,
where
we
can
put
those
constraints
in
place.
C
C
D
Yeah
safety
constraints
on
it.
I
guess
the
only
other
thing
in
thiago
tell
me
if
this
is
not
the
right
way
to
phrase
this,
but
at
least
for
the
time
being,
once
we've
got,
this
implemented
we're
pretty
much
going
to
leave
it
running
in
parallel
with
the
existing
scanners
and
the
report
processes,
because
they
are
not
going
to
be
able
to
migrate
immediately
and
because
they've
got
these
formats
out
there
we
do
have
third
parties
using
them
already
we'll
have
to.
D
This
is
on
me
to
come
up
with
the
the
messaging
and
the
timing
on
this,
but
a
basically
a
deprecation
plan,
so
we'll
sort
of
be
migrating
things
to
this
new
model
for
a
while,
and
it
may
be
that
nobody's
using
it
initially.
My
goal
would
be
to
get
a
new
third
party
up
and
running
on
it
quickly,
so
that
they
can
show
quick
time
to
value
and
then
it'll
gain
some
momentum
internally.
D
It
and
the
fuzzing
team
yeah
that's
kind
of
where
it
came
from
so
I'd
like
this
to
be
the
net
new,
build
forward
kind
of
like
what
we've
done
with
the
graphql
api.
We
just
said:
okay,
we're
not
getting
rid
of
the
old
restaurant,
we're
going
to
keep
it
there,
but
we're
putting
all
the
new
stuff
in
graphql.
C
D
C
D
That's
a
good
question,
I
think,
from
a
like
a
purely
design
design
perspective
from
you
know
from
andy.
I
don't
know
if
we
need
anything
in
the
short
term
since
it's
going
to
be,
I
mean
eventually
we'll
have
to
define
like
what
do
all
these
rendering
components
look
like,
but
I
think
there's
the
old
issuer,
epic
that
you
and
I
were
chatting
about
yesterday-
it's
on
my
to-do
list
to
make
a
new
one
or
to
rewrite
that
one.
C
Yeah,
I
don't
know
if
andy
saw
the
the
the
demo
and
the
screenshots,
but
if,
if
up
to
you,
if
you,
if
you'd
like
a
design
issue
with
the
with
the
screenshots,
so
it's
clear
to
everyone
what
it's
going
to
look
like
or
what
the
possibilities
are,
because
it's
kind
of
block
building
thing.
You
can't
have
a
screenshot
for
everything.
But
you
can
have
the
basic
examples.
E
Yeah,
I
think
we
have
an
issue
open
for
like
updating
the
page
styling
of
vulnerabilities.
I
think
in
that
I
was
going
to
take
james's
almost
like
components
themselves
and
just
kind
of
help
build
out
for
the
other
teams
like
what
you
can
kind
of
puzzle.
Piece
together
to
you
know,
help
your
own
findings
or
results
right.