►
From YouTube: BrownBag: Generic Security Reports
Description
This is the recording of a BrownBag presentation on introducing generic security reports in GitLab. https://gitlab.com/gitlab-org/secure/brown-bag-sessions/-/issues/35
A
A
I
don't
know
how
long
ago
it
feels
like
a
long
time
ago,
but
about
having
a
generic
report
type
and
everything
that
would
entail
and
what
that
would
mean
to
us
some
of
the
benefits
and
impacts
it
would
have
on
our
team
and
integrators.
So,
let's
move
on
with
our
presentation.
So
who
am
I?
My
name
is
james
johnson,
I'm
a
staff
security
engineer
on
the
vulnerability
research
team
and
I
should
kind
of
point
out
that
I
am
a
bit,
maybe
not
biased,
but
the
direction
I'm
coming
from
on.
A
A
It
impacts
everybody,
but
that's
kind
of
the
direction
that
I've
been
viewing
this
from,
and
these
are
links
to
prior
discussions
that
we've
had
that
we've
had
on
this.
This
is
the
main
one
restructuring
the
security
reports.
This
is
also
very
closely
related
and
was
spun
off
of
restructuring
the
security
report,
it's
specifically
about
tracking
the
vulnerability
tracking
vulnerabilities
in
an
evolving
project.
A
So
if
you
have
a
generic
security
report,
you
need
to
also
be
able
to
track
vulnerability,
vulnerabilities
throughout
a
project
generically
and
not
specific
to
an
analyzer
type.
So
that's
why
that
one
got
spun
off,
and
these
are
two
previous
related
merge
requests.
These
aren't
the
proof
of
concept,
merge
requests
that
I'm
talking
about
today
or
using,
but
these
definitely
influenced
things
that
I'm
gonna
show
right
now
all
right.
A
A
So
before
we
really
get
into
the
technical
details,
I'm
going
to
kind
of
tell
a
story
about
what
that
impact
would
mean.
So,
let's
imagine
that
we
have
time
traveling
saboteurs
who
have
targeted
git
lab,
and
this
is
in
the
future
future
gitlab
managed
to
catch
them
in
time
before
any
damage
was
caused.
But
how
did
they
do
this?
A
A
I
don't
remember
what
was
supposed
to
be
on
that
page.
So,
oh,
that's
right.
I
added
animations
all
right,
so
the
security
team
looked
into
it
and
this
is
what
they
discovered.
Multiple
repositories
were
affected,
something
in
common
with
all
the
repositories.
They
all
shared
a
common
ci
configuration,
and
so
they
were
thinking.
Maybe
they
could
add
a
custom
analyzer
to
help
detect
these
anomalies
and
get
repositories
and
stop
whatever
shenanigans
are
going
on
with
the
time
travelers.
A
So
the
developer,
though,
thought
about
how
much
effort
it
took
to
integrate
new
analyzers
in
the
past,
how
frontend,
backend
database
and
schema
changes
all
had
to
be
made
before
they
could
start
using
a
new
analyzer
and
specifically
about
this.
It's
not
just
a
new
analyzer
that
conforms
to
existing
report
types.
A
This
is
specifically
about
adding
an
entirely
new
report,
type
that
doesn't
conform
to
what
gitlab
already
supports-
and
here
are:
let's
see,
can
you
I
don't
know
if
you
guys
can
see
the
little
window
that
I'm
moving
around
that
has
everyone's
faces,
but
so
these
are
some
statistics
that
I
pulled
together.
So
the
number
of
files
and
those
are
spread
out
across
the
merge
requests,
they're
not
unique
files.
I
just
looked
at
all
of
the
merge
requests.
A
It
was
spread
across
at
least
five
merge
requests
involves,
1500,
editions,
three
deletions
and
impacted
30
file
changes
and
coverage,
guided
fuzzing
across
four
merge
requests,
1300
changes,
71
deletions
and
that
occurred
across
77
different
file
changes
again,
not
unique,
there's,
probably
a
lot
of
changes
in
the
merge
request
that
occurred
on
the
same
files.
So
this
developer
was
thinking
about
how
much
effort
it
took
and
also
that
there
was
not
a
relevant
report
type
for
detecting
time
travelers.
A
A
I
don't
know
if
there's
a
word
for
it
schema
if
I'd
analyzer
reports,
those
changes
would
require
no
front
end
back
in
database
or
schema
changes,
so
the
security
team
they
decided,
since
we
have
a
common
ci
configuration
for
all
of
these
repositories
that
are
impacted,
they're,
going
to
write
a
new
job
that
directly
implements
an
analyzer
in
the
job
itself
and
spits
out
a
gitlab
security
report.
Report
type
oh,
and
I
did
actually
implement
this
and
we
can
walk
through
it
later
so,
and
this
is
what
they
wrote.
A
They
have
a
utility
cli
tool
that
they
can
use
from
the
command
line
to
initialize
and
add
vulnerabilities
to
a
report
json,
and
so
they
mix
that
with
a
bunch
of
git
commands
to
find
any
git
commits
that
occurred
in
the
future
that
occurred
before
today's
date
and
so
having
this
in.
The
merge
request
pipeline
means
that
you
can
block
a
merge
request
if
you
think
it
came
from
a
time.
Traveler.
A
A
Maybe
it
didn't
go
high
enough
on
the
version
number,
but
so
this
is
a
output
from
a
quick
analyzer
that
the
security
team
put
together
in
order
to
detect
these
time
travelers,
and
so
in
less
than
an
hour,
they
had
the
custom
analyzer
the
custom
security
report,
custom
information
and
the
vulnerability
details
and
they
saved
gitlab
from
whatever
the
time
traveler
saboteurs
are
trying
to
do
now.
People
heard
of
this
success
other
teams
within
gitlab,
and
so
they
wanted
access
to
the
security
report
that
was
produced
by
the
time
traveler
analyzer.
A
So
it
inherits
everything
it
conforms
to
the
generic
report
format
and
then
it
defines
specific
fields
and
their
types
that
are
still
using
the
free
form,
data
types,
but
are
specific
to
the
time
traveler
output.
And
so,
if
anyone
wanted
to
know
what
to
expect
from
that
output,
they
could
use
the
schema
and
work
off
of
that.
A
All
right
so
story,
time's
over,
I
felt
like
a
story,
would
kind
of
help
paint
the
picture
of
the
potential
impact
this
would
have
and
really
once
I
had
all
the
tools
in
place.
So
I
was
acting
as
this
security
team
right
writing
this
once
I
had
all
the
proof
of
concept
code
plus
this
report
tool
that
created
the
report
on
the
command
line.
I
really
did
create
this
in
maybe
half
an
hour
or
so
yeah.
A
A
Oh
and
that
time
traveler
report
on
the
vulnerability,
dashboard
or
security
dashboard,
it's
all
up
and
running.
So,
if
you
want
to,
if
you
want
me
to
pull
it
up,
we
can
look
at
it
and
tweak
things
and
see
what
happens
all
right.
Otherwise,
oh
I
am
not
watching
the
google
doc.
I
just
need
to
put
that
on
my
other
monitor.
A
B
A
A
Remove
that
all
right?
So
here
on
the
right,
this
is
the
report
itself
and
here
on.
The
left
is
what
created
the
report,
and
this
did
actually
run.
This
tool
was
a
kind
of
I
was
planning
on
doing
something
like
this
anyways,
but
I
kind
of
needed
it
for
the
demo
to
demonstrate
the
impact
of
zero
cost.
Analyzer
integrations,
but
this
tool
does
exist,
and
so
this
creates
the
report.
Actually,
no,
this
doesn't
create
it.
A
And
oh
this,
there
are
some
things
about
the
gitlab
code
base
that
I'm
not
entirely
sure
about
it's
like
the
categories.
I
there
are
categories
and
ultimate
features
in
the
proof
of
concept
for
the
gitlab
code
base.
I
didn't
add
a
security
type
for
those
I
wasn't
sure
if
I
needed
to
so.
If
you
see
me
still
using
sas,
I'm
kind
of
piggybacking
off
of
those
code
changes
or
what
currently
exists,
because
I
hadn't
gotten
to
that
yet,
but
here
we're
adding
a
report,
a
vulnerability
to
the
report.
A
This
is
the
name
of
it
and
that's
the
message
and
here's
the
description
of
it
but
yeah.
This
is
all
set
from
the
command
line,
and
this
is
actually
used
as
the
tracking
field
inside
of
the
vulnerability.
So
how
we're
currently
using
the
location
field
for
each
vulnerability
to
tell
if
a
vulnerability
is
unique.
A
The
generic
report
type
adds
the
tracking
field
so
that
we
can
do
that
generically
and
not
specific
to
a
report
type-
and
this
is
this-
is
extra
data
that
goes
into
the
details.
Fields-
and
so
is
this
one-
and
this
is
adding
a
made
up
identifier
to
the
identifiers
field
of
the
vulnerability,
and
this
is
again
extra
details
about
it.
Did
you
want
to
look
at
more
at
the
json
seth.
B
A
A
A
Yes,
these
are
exactly
what-
or
this
is
the
big
change
is
putting
details
about
the
vulnerability
into
here,
instead
of
having
them
up
here
and
yeah.
Each
of
these
are
they
all
have
a
type
field,
and
that
says
what
type
that
well,
obviously,
that
field
is
and
the
ui
has
a
one-to-one
mapping
for
every
type.
It
knows
how
to
render
it
and
they
can
be
nested,
yeah
and
cameron.
You
had
mentioned
what
about
internationalization,
so
it
got
me
thinking.
A
A
Well,
it's
it's
roughly
in
place,
yeah,
it's
using
the
same
so
on
the
view
side
we're
using
jed
and
git
text
to
translate
things.
This
constructs
that
data
dynamically
from
these
different
language
or
from
the
language
array
right,
yeah
and
it
uses
by
default
the
language
of
the
person
viewing
it
but
yeah.
So
this
report
directly
creates
so
I've
actually
got
two
separate
here.
I'll
just
pull
this
up.
This
will
be
easier.
A
A
All
right
so
time
traveler
should
be
in
here
commit
from
a
time
traveler
there
we
go
and
that's
exactly.
What
shows
up
is
that
data
from
the
report
is
exactly
this,
and
so
this
is
a
commit
specific
field.
So,
even
though
they
are
typed,
they
don't
have
to
be
just
basic
types.
They
don't
have
to
be
just
a
text
or
you
know
a
list.
We
could
have
complex
types
that
are
reusable
and
then,
as
we
improve
on
them,
it
will
improve
everything
that
uses
them.
So
this
commit
one.
A
Yeah
so
there's
a
names
list
and
then
just
a
list:
a
table
text,
url
code,
integer
and
a
commit
file,
location
and
module
location,
and
so
I
figured
this
was
a
pretty
decent
set
of
things
that
we
could
start
with,
or
at
least
for
proof
of
concept
that
I
wanted
to
show
and
there
I
was
trying
to
get
a
markdown
field
to
work.
We
were
talking
about
that
in
the
issue
description.
A
No,
no,
it's
not
it's
just
how
exactly
you
want
to
go
about
doing
it.
Yeah.
I
found
one
place
in
our
code
base
where
I
I
don't
know
what
a
notebook
is
in
gitlab
there's
a
there's,
some
ui
frontend
code,
specifically
about
notebooks
that
uses
a
javascript
native
javascript
markdown
renderer,
but
I
couldn't
find
anything
that
used
it.
So
I
didn't
go
that
route.
A
A
So
I
guess
two
of
them,
for
what
we
currently
have
are
especially
interesting
to
me
would
be
a
http
request
where
you
we
could
work
on
that
component
and
improve
it
where
it
could
show
like
a
curl
request
that
you
can
copy
and
paste.
That
would
do
the
exact
same
thing
as
the
request
itself.
We
could
make
it
show
up
or
as
a
downloadable
like
wireshark
packet.
A
It
puts
together
the
module
name
and
the
offset,
and
that's
all
it
does,
but
you
could
improve
it
to
show
actually
grab
that
build
artifact
and
show
the
object
dump
at
that
location
and
show
the
raw
disassembly
that
it's
pointing
to
yeah.
So
that's
where
I
could
see
that
going,
but
yeah
there's
a
lot
of
different
ways.
This
could
go
and
for
the
time
traveler
one
we
could
have
a
time
traveler
specific
component.
That
is
more
involved.
You
know
yeah.
A
A
Oops,
don't
need
to
look
at
the
job
itself,
so
when
I
was
testing
this,
I
just
had
a
static,
gl
security
report.json
that
I
was
manually
editing.
While
I
worked
on
the
ui
but
yeah.
This
is
using
a
table,
a
commit,
a
list
of
urls,
a
raw
text
block
a
code
block,
and
this
is
a
name
list
nested
inside
of
the
main
one
right.
So
you
can
nest
these
lists
as
much
as
you
want,
and
that's
what's
happening
right
here.
A
Yeah
we
have
about
half
an
hour
left
or
20
minutes
all
right,
so
I
mentioned
internationalization.
This
is
a
little
rough,
the
language
field.
It
doesn't
enforce
the
language
value,
so
you
could
really
put
whatever
you
want
right
there,
but
it
does
work,
and
these
are
the
view
components
themselves
again,
like
I
said,
a
one-to-one
mapping
pretty
much
of
all
of
them.
A
There
is
an
extra
view
component.
If
you
happen
to
dig
into
it,
the
label
is
not
exposed
to
the
user
and
yeah.
This
is
that
nested
example
that
I
showed
you
and
the
tracking
field.
I
did
mention
this.
There
was
a
reason,
a
need
for
it.
For
this
proof
of
concept,
I
was
trying
to
not
mix
the
two
discussions
about
tracking
vulnerabilities
and
having
a
generic
report,
but
I
kind
of
needed
to
since
the
generic
report
needs
to
be
generic.
A
A
A
So
this
is
all
created
based
off
of
the
core
data
types,
and
so
as
new
types
become
available
and
improve,
the
third
party
integrators
would
definitely
be
able
to
use
any
of
that.
Does
that
answer
your
question
tiago?
Yes,
it
is.
Thank
you
awesome
and
matt
says
how
close
is
this
to
being
to
being
something
we
could
work
towards,
moving
to
or
start
moving
to?
A
What
are
the
steps
needed,
what
might
break
what
are
the
risks
and
the
unknowns
so
the
way
I
implemented
this
right
now
it
doesn't
touch
the
way
things
are
currently
done
with
sas
and
everything
else.
I
in
the
discussion
issue,
I
had
tried
to
lay
out
a
smaller
mvc
where
we
added
details
field
and
then
later
we
added
a
fully
generic
security
report
type.
It
didn't
really
make
sense
once
I
got
into
implementing
it
to
do
it
that
way.
A
A
A
Yep,
exactly
and
so
related
to
that
there
is
a
reason
why
I
added
so
cameron.
You
had
some
questions
about
the
schema
itself.
If
we
wanted
to
transition
some
of
the
existing
report,
types
to
this
we
wouldn't
have
to,
but
if
we
wanted
to,
we
could
do
it
this
way
right
where
we
inherit
from
the
generic
report
type,
and
then
we
define
the
specific
fields
that
that
specific
analyzer
spits
out
and
then
output
from
that
analyzer
would
conform
to
the
generic
type
as
well
as
this
analyzer
specific
one.
A
At
that
stage,
yeah
the
analyzer
specific
schemas
would
become
more
informational
and
wouldn't
be
tightly
bound
to
or
may
not
be
tightly
bound
to
code
in
gitlab
yeah.
So
it's
a
there
there's
benefits
to
doing
this.
It
would
make
it
easier
to
or
you
would
get
the
improvements
of
the
view
components
reflected
in
the
vulnerability
dashboard
for
like
a
sas
or
das
report.
D
A
No,
it
was
more
so
going
through
the
story
and
kind
of
painting
the
broader
picture.
I
was
trying
to
keep
it
a
bit
more
high
level
and
not
dive
super
deep
into
the
code.
So
if
you
have
questions
yeah,
please
go
for
it.
I
think.
Okay,
let
me
just
double
check
yeah.
I
just
have
a
few
summary
slides
going
over
things.
Actually,
let
me
cover
those
first
and
then
we'll
have
plenty
of
time
for
questions,
and
I
can
pull
up
code
and
yeah
all
right.
A
A
This
is
one
of
the
biggest
wins
in
that
area,
so
we
would
be
able
to
implement
a
new
analyzer
type
that
doesn't
conform
to
any
of
our
existing
schemas
and
start
using
it
immediately
without
any
back-end
code.
Changes
no
front-end
code
changes,
no
database
changes
and
no
schema
changes
once
that
proof-of-concept
is
something
that
we
want
to.
A
I
guess
make
more
official
and
let
users
know
what
type
of
data
to
expect
in
the
report.
Then
we
could
write
a
schema
for
it,
but
we
wouldn't
need
the
schema
in
order
to
have
the
analyzer.
So
to
me,
that's
one
of
the
bigger
ones
on
this,
at
least
from
iterating.
It
also
helps
integrators.
They
have
a
lot
more
control
over
the
content
that
shows
up
in
the
details
field
and
it
makes
the
analyzer
development
accessible
to
anyone.
A
That
was
something
I
came
up
with.
After
I
came
up
with
three
other
ones,
so
I
did
add
another.
Oh,
how
do
I
get
out
of
this
here?
We
go
so
if
we
go
back
here,
come
on
click,
all
right,
I'll
need
to
go
to
a
different
job,
so
I
did
add
three
different
security
scanners
or
analyzers.
I'm
not
sure
if
I
would
call
the
jobs
analyzers,
but
I
guess
they
are
they're
producing
a
security
report.
A
I
had
three
different
ones:
one
to
flag
any
python
files
that
it
finds
in
the
project,
another
one
to
check
all
commits
in
that
merge,
request
to
make
sure
they're
signed
or
make
sure
they
have
a
valid
gpg
signature,
and
if
they
don't
it's
a
security
vulnerability
and
then
the
other
one
was,
let's
see,
forbid
python.
Oh,
I
guess
time
travel
was
my
third
one
yeah,
but
yeah.
So
these
are.
I
could
see
these
definitely
being
useful.
A
B
A
All
right,
sorry
about
that.
So
this
one
specifically
for
bids
python
and
all
it
does-
is
find
all
the
python
files
and
add
a
vulnerability
for
each
of
them
and
that's
it.
I
was
trying
to
figure
out
ways
to
make
this
process
even
easier,
but
we
still
need
that
data
there's
no
way
getting,
there's
no
way
to
get
around
it.
So,
but
as
far
as
that
goes
this
really
isn't
that
bad
all
right
so
cameron.
I
know
you
have
questions
and
are
waiting.
A
I
think
I've
covered
most
of
it,
so
improvements
yeah
improvements
to
one
of
the
one
view
component
will
improve
all
everyone
that
uses
those
view
components
and
it
won't
be
tied
to
specific
report,
rendering
or
renderer
yeah
set
stage
for
more
advanced
vulnerability
tracking,
and
so
I
did
want
to
point
out
a
few
things
that
it
doesn't
mean.
It
doesn't
mean
that
we
can't
still
provide
for
scanner
specific
schemas
like
we
definitely
can,
and
they
don't
even
have
to
be
the
generic
report
type.
A
But
then
you
may
not
get
the
benefit
from
having
those
view
components
as
those
improve,
and
then
this
also
doesn't
mean
that
we
can't
have
scanner-specific
ui
components
that
expect
a
certain
schema.
We
definitely
can
still
have
that
we
could
have
a
sas
or
dest
specific
view
of
that
report
too.
All
right
so
moving
on
to
you
cameron.
What
did
you
want
to
cover.
D
I
mean
I
don't
have
too
much
I
I
would
say
that
one
of
the
things
I've
I've
struggled
with
this
is
there's
pieces
of
this-
that
I
really
like
and
there's
pieces
of
this-
that
I'm
not
sure
about
yet.
So
as
an
example,
I
really
like
the
concept
of
the
details
field
and
the
fact
that
it's
generic,
I
like
the
I
like
how
you've
listed
it
up
in
schema.
I
like
the
fact
that
it
means
the
schema,
wouldn't
change
and
then
it's
easy
for
integrators
to
add
new
fields.
D
The
concept
of
adding
generic
data
does
have
limitations
in
terms
of
analytics
in
terms
of
how
you
store
it
in
the
database.
In
terms
of
you
know
how
you're
not
sure
what
to
show
on
the
ui,
because
you're
not
sure
about
the
constraints
of
the
data,
but
I
mean
if
people
are
happy
with
those
limitations,
then
I
think
that's
a
sensible
path
to
follow.
D
E
D
A
That's
actually
some
of
the
changes
that
I
mentioned
that
I
hadn't
gotten
to.
That
is
one
of
them
where
it
so
I
let's
see-
let's
say
I
have
my
own
scanner
type
right,
I'll,
just
call
it
custom
right
then
like
should
that
even
show
up
in
the
drop
down
like
we
could
just
iterate
through
all
the
vulnerabilities
in
the
report
and
grab
whatever
scanner
name
was
declared
and
show
that
in
the
drop
down
we
could
do
that
right
now.
A
A
You
will
definitely
need
to
know
where
the
fields
are
so
a
schema
for
that
would
be
required.
If
you
want
to
do
that
type
of
thing
and
then
it
needs
to
be
searchable
right.
So
postgres
has
the
json
b
field.
I
had
pretty
dang
sure
it's
not
as
performant
as
just
having
its
own
database
column
right.
So
you
are
still,
let's
see
if
you
don't
want
to
pull
individual
fields
out
into
their
own
columns.
A
That
does
limit
you
and
you're
100
right
on
that,
and
the
problem
is
that
we
don't
know
what
we
don't
know
if
we
don't
know
why
we
might
want
those
fields
in
the
future,
and
so,
if
all
that
data
is
just
in
a
json
b
field,
then
we'll
be
limited
by
one
having
a
schema
and
knowing
what
those
fields
are
and
then
two
whatever
performance
and
querying
limitations,
json
b
fields
have
yeah.
It
is
definitely
a
trade-off
yeah.
I.
D
On
that,
though,
like
I'm
not
saying,
that's,
not
the
right
trade-off
to
take,
and
particularly
right
now,
because
I
would
say
that
our
secure
solution
is
still
fairly
young
and
immature.
So
it's
like
if
in
like.
You
know
five
to
ten
years
when
we've
got
a
hundred
other
fields,
then
maybe
there's
no
point
for
a
details.
Field
anymore,
because
we've
captured
most
of
the
space
or
maybe
there
still
is,
but
in
in
terms
of
your
in
terms
of
the
json
b
and
the
indexing.
So
json
b
does
have
an
index.
A
Because
we
have
defined
types
right,
so
I'm
actually
not
sure
that
jsonp
indexing
needs
to
be
on
specific
fields.
I
think
it's
more
about
being
able
to
quickly
find
the
right
fields
in
the
json,
and
so
it
indexes
all
the
fields
I
haven't
used
it
directly.
I've
read
the
documentation
for
it
twice,
maybe
one
and
a
half
times
so.
B
E
D
D
B
No,
I
you
know,
if
that's
the
case,
it's
a
generic
field
and
you
want
to
be
able
to
search
it.
You
have
a
new
schema
and
you
say
hey.
This
is
now
a
typed
field
and
it's
no
longer
part
of
the
generic.
You
can
leave
it
in
there
and
we'll
handle
it
as
a
generic
field.
But
if
you
want
it
searchable,
you
throw
it
up
as
a
as
a
strongly
typed
field.
A
B
A
B
A
A
A
D
Although
so,
my
understanding
is
that
you
would
probably
have
some
kind
of
so
elasticsearch
defines
a
mapping
which
is
in
json,
there's
no
reason
why
you
couldn't
put
the
details
kind
of
mapping
directly
into
elasticsearch,
but
I
would
have
thought
that
that
would
be
fairly
sub-optimal
because
it
has
different
fields.
It
would
have
the
same
indexing
problem,
so
you
could.
A
I'm
not
an
expert
of
elasticsearch,
you
could
probably
you
could
collapse
the
json
down
and
change
all
the
field
names
to
just
be
their
path
in
the
json
document,
instead
of
an
actually
nested
hierarchy
that
might
help
a
little
bit.
I
don't
know
I
actually
hadn't
thought
about
that.
So
do
we
use
do
we
have
any
search
capabilities
right
now
on
the
vulnerability
dashboard.
I
know
we've
got
sword
in
no.
F
That
was
something
we
had
a
sort
of
a
rough
draft
of
a
plan
for
that
in
the
future
and
at
the
time
the
advisement
was.
We
are
not
at
a
place
where
it
would
be
probably
proven
for
us
to
proceed
forward
with
that.
They
need
to
make
some
more
changes
and
I
think
an
improvements
to
the
search
infrastructure
get
lab
wide
okay,
but
it
is
something
that
we've
looked
into.
We
may
get
it
actually
sooner
than
that,
potentially
on
the
reverse
side
and
adding
vulnerability
results
to
some
of
the
existing
global
search
capabilities.
A
D
A
Extreme
so
an
example
of
types
of
fields.
Actually
I
might
have
this
up
so
I
a
few
jobs
ago,
I
wrote
a
fuzzing
framework
and
it
focused
not
so
much
on
the
tool
itself,
but
more
handling
the
automation
of
spinning
up
environments
and
capturing
results
and
searching
through
it,
and
I
use
a
mongodb
database
for
that.
A
So
it's
it's
all
json
basically,
but
I
did
expose
just
basically
direct
query
and
functionality
where,
if
I
knew
the
schema
of
the
type
of
data
coming
out
of
the
fuzzer,
then
I
would
be
able
to
search
for
like
find
me
all
crashes.
Where
eax
is
this,
and
it
is
this
type
of
crash,
and
it
is
this,
but
it's
not
quite
what
we're
going
for
here
and
and
even
as
far
as
buzzing
goes.
That's
not
quite
the
use
case
for
it,
but
being
able
to
dig
down
into
that.
A
A
Let's
see
so
all
right
so
seth
said
I
like
that
third
parties
can
add
fields
without
asking
for
changes
to
the
schema
yeah.
That
is
what
I
was
trying
to
demonstrate
with
the
time
traveler
example,
which
was
really
fun
by
the
way
yeah.
It
was
so
you
can
expose
a
schema
if
you
want
to
share
it
and
let
other
people
know
what
to
expect,
but
you
don't
have
to,
and
it
really
does,
the
concept
of
zero
cost
integrations.
A
I
think,
is
going
to
have
a
bigger
impact
than
we're
kind
of
thinking.
Right
now,
even
at
least
for
me
in
the
past,
making
eliminating
that
degree
of
bottleneck,
it's
always
been
hard
to
tell
how
big
of
an
impact
it
would
have,
or
I've
always
kind
of
underestimated
it.
So
I'm
I'm
pretty
excited
about
that.
B
A
E
I
have
I
have
a
self-interested
question
because
just
before
this
seth
and
matt
and
lindsey-
and
I
were
talking
a
little
bit
about
that
comment-
that
matt
made
on
the
markdown
idea-
yeah,
which
is
which
is
a
subset
of
what
you
propose.
This
is
a
lot
more
powerful
and
solves
a
lot
more
of
the
problems
that
we
have,
and
I'm
kind
of
wondering
should
I
even
bother
but
like
it
doesn't
sound
like
this-
would
be
a
whole
lot
more
work
than
doing
the
markdown
thing,
and
this
just
sounds
better.
A
So,
let's
see
so,
if
you
wrap
it
up,
I
couldn't
find
an
existing
view
component
that
just
rendered
markdown
from
a
json
blob
or
well.
There
was
one,
but
I
was
iffy
about
using
it.
So
if
you
either
figured
out
how
to
do
that
and
just
went
with
what
you're
currently
planning
you,
we
could
reuse
that
with
this
right,
I
don't
see
there
being
that
much.
B
E
B
E
And
and
and
the
markdown
I
think,
is
a
little
bit
for
convenience
right,
you
could
use
erb
or
hamo
or
or
any
other
templating
engine
it's
just
about.
How
much
do
you
want
to
allow
or
how
much
work
is
it
to
make
that
user
vendor
data
secure?
Otherwise
they
could
be
writing
javascript
straight
into
our
dom.
You
don't
want
that.
I
think.
E
A
Yes,
I
am
very
biased,
although
I
will
say
I
did
copy
a
lot
of
our
existing
view
components,
so
they
shouldn't
have
fallen
too
far,
they're
just
missing
tests
and
probably
some
documentation
but
yeah.
I
know
I
I
I'd
be
willing
to
help
make
that
work
too.
As
far
as
having
a
view
a
generic
markdown
component
I
mentioned
earlier.
E
A
B
Yeah-
and
it's
also
where
you
shift
the
work
right,
so
in
this
case
the
work
is
on
the
thread
insights
or
on
the
dashboard
team,
whereas,
if
you're
just
rendering
out
markdown,
then
the
work
to
figure
out
what
that
markdown
is
is
on
the
analyzers
teams.
So
it
it
kind
of
depends
on
where
we
want
that
to
to
sit
so
like
in
what
we
saw
today.
If
it
doesn't
support
a
certain
kind
of
display,
we're
stuck
until
threat,
insights
or
who's
ever
managing
that
that
view
stuff
can
build
it
well.
E
B
Yeah
and
I
would
say
the
view
components
like
the
architecture,
it's
very
easy
to
add
another
component
right
if
we
have
a
bulleted
list
or
a
numbered
list
or
whatever
we
can
do
that
without
too
many
conflicts,
like
that's
pretty
straightforward
yeah,
it's
certainly
much
cleaner
than
going
into
the
code
today
and
just
doing
some.
If.
A
Statements
so
I
I
will
say
there
is
an
important
point
that
I
didn't
quite
get
to
for
the
proof
of
concept.
The
typed
fields
definitely
need
to
be
versioned,
as
well
as
the
view
components
right,
and
so
let's
say
we
make
breaking
changes
to
the
list
component
right.
We
need
to
still
be
able
to
render
those
old
reports,
so
that
would
definitely
be
a
part
of
it
yeah.
I
wanted
to
have
it
in
the
code
for
this,
but
I
did
have
to
stop
and
start
making
slides
and
everything.
D
D
A
C
A
A
A
E
B
D
A
Right
right,
yeah-
and
I
can
explain
a
little
bit
more
about
that.
So
the
reason
why
the
proof
of
concept,
so
the
proof
of
concept,
is
more
about
adding
the
generic
report
type.
It's
the
best
way
to
kind
of
demonstrate
everything,
but
in
order
to
add
the
generic
type,
we
I
needed
the
details
field
and
I
needed
the
tracking
field.
A
F
F
I
guess
I'd
need
to
understand
a
little
bit
more
exactly
where
the
work
is
for
us
versus
the
scanner
teams
it.
It
sounds
like
if
I
heard
that
correctly,
we
could
go
down
a
path
of
implementing
this,
and
then
the
scanner
teams
could
sort
of
jump
on
as
they're
ready
it
wouldn't
have
to
be
a
one-shot
deal
which
I
like
yeah.
G
B
F
I
think
if
I,
if
I
assume
that
this
would
fit
with
where
I
had
it
on
kind
of
current
roadmap
plan,
I
think
it's
13.5.
I
was
looking
to
start
some
of
the
more
like
code.
Structural
data
changes
for
things
in
support
of
mostly
the
mr
changes,
the
improvements
there,
but
I
think
this
kind
of
goes
a
little
bit
broader
than
that.
F
B
B
F
E
If,
if
I,
if
I
may
matt,
we
have
that
epic
coming
up
about
moving
moving
raw
metadata
to
their
own
tables,
it
sort
of
overlaps
with
this
sort
of
knot,
but
there's
also
the
epic
around
their
integrity
of
the
whole
question
about
vulnerabilities
versus
vulnerability
findings.
There
are
no
fields
there.
There
are
fields
that
are
copied
across
both
tables
and
I
I
feel
like,
if
we're
going
to
make
something
more
generic
and
we
need
to
support
something
more
generic.
E
I
I
would
love
to
fix
these
problems
before
we.
We
build
on
top
of
the
current
database
model.
To
avoid,
I
don't
know
if
it's
part
of
what
cameron
was
was
feel
for
war,
but
it's
what
I
am
it's
are
we
building
on
sand
here
and
are
we
gonna
introduce
even
more
weird
corner
cases
that
we
didn't
foresee
if
we
don't
tighten
down
the
models.