►
Description
Matt and Thiago talk mostly about the security report schema and its relationship to the vulnerability report Tool filter.
A
All
right,
so
we've
got
just
me
and
thiago
today,
a
couple
of
other
discussion
items.
Nothing
else,
I'll
read
this
out
loud
just
for
anyone.
That's
watching
the
video
later
becca
is
not
for
this
week's,
but
for
next
week
she
has
some
agenda
items
she's
going
to
put
on
there
around
some
design
questions.
She
would
encourage
everyone
to
attend
if
you
can,
or
at
least
check
the
meeting
notes
front.
End
engineers
in
particular.
A
There
are
a
few
things
that
we've
got
in
the
research
design
phase
that
we
would
like
a
lot
of
input
on
so
that'll
be
good.
The
question
tiago
and
I
were
just
started
chatting
about
threat
insights
monthly
office
hours
calls,
so
these
have
been
happening
regularly
for
well
over
a
year
now.
I
think
at
this
point
once
a
month.
A
The
original
goal
was
to
try
to
get
folks
from
outside
of
our
team
to
come
and
join
where
it
could
be
more
of
a
centralized
location
for
people
to
ask
questions
have
some
interaction
with
the
threat
inside
team
if
they
needed
to
I've
been
attending
these
fairly
regularly?
When
I
can
for
months-
and
it
seems
like
we-
don't
really
have
anybody
attending,
except
for
occasionally
a
few
insights
folks,
nobody
from
outside
the
team
is
going.
B
And
before
we
started
recording,
I
was
saying
that
that
people
seem
happy
to
ask
questions
in
in
slack.
I'm
writing
that
down
now
and
and
it's
been
working
well,
most
most
questions
getting
answered
on
the
same
day.
Sometimes
they
extend
over.
You
know
the
discussions
then
extends
over
for
a
few
days,
but
in
general
it's
working.
Well,
I
think
so.
I'm
I
mean
I'm
I'm
supportive
yeah.
A
I'm
excited,
I
guess,
I'm
I'm
kind
of
wondering.
Is
it
worth
so?
I
think
the
questions
kind
of
come
in
in
two
varieties.
Most
of
them
fall
into
the
bucket
of
oh
yeah.
We
know
that
answer.
We
can
answer
really
quickly
for
somebody,
I'm
wondering
if
the
things
that
people
want
to
dig
into
a
little
deeper,
if
maybe
that
was
kind
of
the
intent
of
the
office
hours
is.
A
If
you
want
something
a
little
bit
deeper
with
the
engineering
team
or
you
know
me,
we
could
have
that
as
a
time
set
aside,
so
that
we're
not
just
ad
hoc
handling
a
lot
of
these
requests.
I'll
admit,
I
hadn't
even
occurred
to
me
for
a
very
long
time
to
try
to
push
people
off
towards
that
meeting.
That's
the
only
reason
I
can
see
keeping
it
is
if
we
feel
like
there's
too
many
questions
that
require
more
like
kind
of
digging
in
and
discovery.
B
It's
funny
you
should
mention
that,
because
I
just
added
something
to
plenty
breakdown
that
it's
not
really
planning
breakdown
and
it
it's
this
sort
of
discussion,
so
yeah,
maybe
maybe
maybe
make
make
it
ad
hoc
and
say
or
or
change,
say
hey.
If
there's
no
agenda,
it's
automatically
cancelled,
I'm
not
gonna
show
up
and
every
now
and
then,
when
there's
an
agenda,
we
do
a
better
job
of
advertising
and
and
drumming
up
people
to
come
in.
A
A
B
A
B
B
Ideally
there
there's
some
other
issues
about
how
we're
using
the
the
feuds
in
the
report,
but
let
me
see
if
I
can
explain
the
gist
this
menu
here,
the
tool
menu
which
is
actually
used
to
filter
the
the
report.
Type
of
vulnerability
is
populated,
based
on
what's
available
on
the
project,
and
our
scanners
will
populate
our
analyzers
or
analyzers
that
integrate
with
gitlab
will
populate
their
report.
B
B
So
traditionally
this
has
been
populated
from
from
a
mix
of
sources,
but
I'll
skip
too
much
of
this.
The
history
just
just
to
say
that
the
way
the
graphql
is
currently
implemented
and
the
way
we're
currently
populating
the
reports-
they're
not
working
well
together.
So
if
you
use
the
the
fields
as
they
meant
to
be,
you
sort
of
break
this
breaks
this
menu.
B
So
there
was
a
proposal
to
sort
of
change.
The
this
structure
here
that
that
separated
the
the
grouped
by
vendors
to
instead
group
by
the
type
or
the
two
the
scan
type
and
then
this
these
fields
are
populated.
It's
explained
here,
so
it's
populated
from
the
analyzer
name,
analyze
vendor
sorry.
This
is
adding
to
it
yeah,
whether
I,
where
is
it
written.
B
Well,
I've
got
lost
matt
there,
you
go,
show
this
k
scanner
name
under
the
report
type
and
the
analyzer
vendor
so
and
I've
been
I've
been
on
this
issue
and
it's
getting
to
my
head.
So
this
is
the
scanner
name,
it
comes
from
scan.scanner.name
and
this
is
the
vendor
name.
It
comes
from
scan
dot,
analyzer,
dot,
vendor
dot
name.
I
think,
and.
B
The
question
the
discussion
that
spawned
was
from
a
very
simple
question
asked
by
by
fabian,
which
was:
can
we
make
scanner
optional
now
that
analyzer
is
required
so
in
in
the
release?
1500
of
the
new
of
the
security
report
schemas,
we
have
scan.scanner
required
and
scan.analyzer
required,
and
I
believe
these
two
fields
are
useful
matt.
B
A
A
B
As
git
lab-
and
then
this
was
part
of
the
discussion
here,
if
I,
if
I
come
right
now
and
and
give
the
correct
information,
say:
hey
the
the
container
scanning
is
by
by
gitlab
and
the
vendor
is
aqua.
This
is
what's
going
to
happen.
It's
gonna.
It's
gonna,
throw
the
an
entry
here
when
this
is
not
really
what
we
meant,
because,
even
though
the
the
scan
is
done
by
aqua,
the
integration
is
done
by
gitlab.
B
A
B
I
agree
with
that.
Cam
did
a
good
job
job
here,
saying
that
summarizing
our
our
choices,
so
you're
saying:
let's
use
the
the
scan
scanner
for
the
name
number,
that's
that's
option
one
and
then
some
analyzers
will
just
have
to
to
create
a
name.
So
what
he
means
by
that
is
using
the
the
case
of
contain
the
container
scanning
analyzer.
B
We
wanted
to
populate
the
menu
like
this,
so
we
would
take
the
scanner
name
and
put
it
here
and
then
we
would
take
the
vendor
the
analyzer
vendor
and
put
it
here.
But
if
I
use
the
analyzer
name
in
the
menu
here,
this
would
show
container
scanning
and
then
container
scanning
again
it's
not
it's
not
a
big
deal
for
for
analyzers.
I
think
it's
a
small
change,
you
can
say
well,
my
analyzer
name
now
is
3v
and
and
and
the
analyzer
vendor
is
called
gitlab.
That's
I
think
that's
that's
an
okay
solution.
B
It
does
need
coordination
so
I'll
get
to
that
the
other
the
other
one
is.
We
stick
just
to
scan
that
analyzer
and
then
he
made
an
argument
that
scan
scanners
is
not
required,
but
I
think
we
want
to
keep
that.
So
if
we're
considering
option
two
it
it
stops
here,
we
don't.
We
don't
say
that
it's
not
required
and
then
the
other
option
is.
B
What
sort
of
were
we
talking
about
here
like
we
use
another
scan,
analyzer
name
and
scan
the
scanner
name,
and
then,
if
the
scan
scanner
name
is
missing,
we'll
just
backfill
with
the
analyzer
name,
it
does
create
a
little
bit
more
work
for
for
threading
sites.
I
don't.
I
don't
particularly
love
changing
the
data
that
was
reported,
but
I
don't
know.
B
If
we're
going
back
to
the
menu
design,
I
don't
think
we're
going
to
have
time
to
settle
the
discussion
and
work
out
what
the
what
the
schema
should
be.
So
I
was
throwing
out
there
and
I
haven't
seen
fabian's
responses.
He
seems
to
be
in
agreement.
Is
that
it's
a
lot
harder
to
to
make
an
optional
field
mandatory,
because
you
change,
you
need
to
change
the
model
name
and
current
integrations
will
have
to
adopt
that
or
they'll
break.
B
So
the
easier.
The
easier
thing
to
do
is
it's
to
make
something:
that's
mandatory
optional.
So
I
was
proposing
that
right,
just
because
we're
looking
to
release
the
scheme
of
1500
in
15.4,
it's
one
or
two
milestones
away,
depending
how
you're
counting
and
if
we
don't
do
anything.
The
release
that
goes
out
requires
both
properties.
It
requires
scandal,
analyzer
and
scan
dot
scanner,
and
my
argument
was
that
we'll
take
our
time
on
this.
B
A
A
I
don't
mean
to
complicate
things
with
the
menu.
I
think
what
I
was
sort
of
pointing
out
is:
we
have
an
existing
menu
structure
going
back
and
reading
through
the
history,
and
I
realized
this
is
many
many
months
ago.
So
I'm
sure
my
my
thinking
on
this
has
changed
a
little
bit,
but
it
started
with
a
proposal
to
restructure
the
current
menu
layout,
based
on
a
limitation
of
the
data
model,
the
apis
that
kind
of
thing
so
seeing
where
the
conversation
evolved
to.
A
A
Good,
so
if
we
do
that
like
this,
so
those
would
be
the
analyzer
names
and
the
secondary
level
menu
is
the
analyzer
name.
If
we
want
to
call
it
that
if
it
doesn't
have
one,
I
think
this
is
where
I
was
saying
we're
already,
essentially
calling
the
analyzer
name
the
same
thing
as
the
tool
type
for
get
lab
analyzers.
A
A
We
would
be
able
to
expose
those
names
as
whatever,
so
you
might
see
spot
bugs
and
es
lint
appear
there.
I
don't
think
we
need
to
concern
ourselves
with
the
scanner
vendor
in
that
context,
because
that's
that's
like
one
layer,
above
kind
of
like
the
none
of
your
business.
Don't
worry
about
it
right
because
it's
that
analyzer
vendor,
who
are
you
going
to
pick
up
the
phone
and
call
that's
why
we
structured
it
this
way
in
the
beginning.
A
B
A
Okay,
so
in
the
meantime,
until
we
decide
to
make
that
required,
it
seems
like.
Could
we
infer
that
from
the
scanner
vendor,
if
there's
no
vendor
property
at
the
analyzer
level,
and
then
the
analyzer
name,
if
not
provided,
would
also
just
be
inferred
from
the
the
report
type
so
that
we
would
continue
with
this
menu
structure?.
B
B
So
I
I
what
I
wanted
to
do
with
my
last
push
there
to
say:
hey,
let's
just
release
this
as
it
is
as
required
is
one
anyone
adopting
that
and-
and
some
analyzer
groups
may
choose
to
adopt
it
as
a
15-4,
I
think
container
security.
Might
it's
not
a
huge
change
to
to
be
honest
in
analyzer,
the
the
worst
part
is
coordinating
what
happens
to
the
menu
and
and
so
on.
B
We'll
have
all
the
data
required
to
build
whatever
menu.
We
feel
suits
best
the
users
and
and
whatever
we're
trying
to
to
do
that
and
is,
as
as
a
result
of
this
discussion,
we
find
out
that
hey
turns
out.
We
don't
need
this.
This
particular
piece
of
information
we
can
make
it
optional,
then
we're
free
to
do
that.
Then
15
iphone,
1,
hyphen,
0
of
the
schema
can
just
say:
you
know
what
scan.scanner
is
now
optional,
because
we're
doing
so
and
so
or
even
the
analyzer,
but.
A
My
tool
name
is
probably
the
specific
branded
name
of
whatever
it
is
that
I'm
offering,
but
the
technology
is
still
going
to
be
it's
a
static,
analyzer,
dynamic,
analyzer
whatever.
So,
if
we're
classifying
it
like
that,
I
I
don't
know
right
like
do.
I
want
to
see
vendor
b
fancy
name
here,
or
would
I
rather
see
this?
Is
vendor
b's
task
tool?
A
B
You
well
well
within
your
your
your
rights,
math
and
and
and
what
I
wanted
to
do.
You
said
before.
Oh
I
didn't
want
to
complicate.
I
I
I
don't
resent
that
at
all.
What
I
really
want
to
do
is
have
that
conversation
without
having
to
worry,
oh,
my
god,
we're
about
to
release
this
and
we're
not
going
to
have
time,
let's,
let's
rush
it
like.
B
So
I
think
that's
a
good
thought
and
my
my
the
side
proposal
there,
the
writer
with
the
proposal
to
release
1500
as
is,
is
that
maybe
we
would
push
this
back
to
design
because
then
we
can
think
of
maybe
even
problem,
validation
or
solution.
Validation,
just
say
hey
what
what
is
this
menu
doing
and
what
do
we
want
to
say
showing
it
all
right?
That's
awesome.
We
managed
to
use
the
whole
rest
of
the
meeting.
B
No
yeah
this
thing
had
had
gone
for
days.
It
was
time
to
have
at
least
one
sync.
I'm
I'm
happy
you
and
I
are
on
the
same
page.
It
looks
like
all
the
engineers
are
coming
together.
There
I'll
wait
to
see
what
others
say,
but
I'm
super
happy
with
this
like
release
1500,
as
is
keep
working
on
this
issue.