►
From YouTube: Planning Discussion: Generic Security Reports
Description
Synchronous discussion to breakdown the work required to implement Generic Security Report Schemas per design issue https://gitlab.com/gitlab-org/gitlab/-/issues/267193
A
All
right
we're
here
to
talk
about
the
unified
report
scheme
and
how
we
can
move
forward.
So
we've
got
a
poc
that
was
delivered
to
us
by
james
johnson
like
three
months
ago
and
it's
fairly
large.
It
includes
some
changes
in
you
know
fingerprinting
and
location
identification,
but
what
I
really
wanted
to
focus
on
today
is
around
the
templated
components,
so
I
know
there's
other
back
back-end
work.
That's
involved
in
this
larger
unified
report
schema
and
I
believe,
a
lot
of
that
is
already
defined
under
this
epic.
A
A
That
would
be
my
my
goal
for
this
discussion.
If
there's
other
questions
or
comments
about
some
of
the
other
back
end
work
me
how
we
can
we
can
talk
about
it,
especially
if
it's
something
that
matt
can
help
clear
up,
but
since
we
don't
have
a
lot
of
representation
from
the
rest
of
the
team
here,
I
was
hoping
that
that
would
be
a
good
focus.
A
C
D
A
D
A
Okay,
now
I'm
gonna
just
summarize
what
I
just
said.
So
you
know
the
the
agenda.
The
meeting
topic
says:
unified
report
schema
given
the
audience
and
the
time
and
our
priority
right
now
I
want
to
focus
on
this
templatized
components
for
the
generic
report
schema,
which
is
you
know,
much
more
more
fun
and
heavy,
which
is,
I
think
why
you
came
to
join
us,
because
there's
a
lot
of
considerations
around
the
secure
front,
end
team
here
as
well
for
sure
thank
you.
A
I'm
gonna
go
ahead
and
share
my
screen
just
to
make
sure
we're
all
looking
at
the
same
thing.
So
overall,
summary
of
what
we're
doing
here
is
available
in
the
epic.
I
think
everyone's
pretty
aware
of
the
fact
that
all
the
different
scheme,
all
the
different
scanners
right
now,
have
their
own
schemas.
A
The
vulnerability
details
page
has
been
updated
to
kind
of
display
or
react
to
those
schemas
in
certain
ways,
and
this
is
a
approach
for
us
to
make
that
generic,
so
that
third-party
scanners
could
introduce
new
schemas
so
that
our
internal
scanners,
which
hopefully
someday
will
start
to
adhere
to
it,
would
have
more
flexibility.
A
And
this
is
the
larger
epic,
but
andy
was
nice
enough
to
create
a
design
issue
for
us
just
for
the
templatized
components.
So
what
we
would
display
on
the
vulnerability
details
page,
so
I'm
going
to
click
into
that
before
I
move
on.
Is
there
any
questions
about
the
bigger
effort
or
matt
anything
that
you
want
to
add
around
the
priority
or
usage
or
anything
like
that?.
E
No,
I
mean
priority.
This
is
something
that's
important.
E
I
think
the
urgency
is,
let's
say
it's
increasing,
so
the
one
of
the
main
benefits
of
this
is
a
lot
of
the
scanner
teams,
as
they're
trying
to
mature
and
advance
their
own
areas
of
the
product
are
finding
that
they
have
need
for
more
very,
like
use
case,
specific
information
to
be
displayed
on
the
vulnerability
details.
Pages
right,
like
a
fuzzing
output
has,
it
might
have
like
a
like
a
crash
dump
of
whatever
happened
in
memory.
E
Sast
may
want
to
put
a
snippet
of
the
actual
code
where
something
is
identified
right
now.
We
don't
have
a
good
way
for
them
to
do
that
other
than
each
team,
basically
hard
coding
in
a
conditional
for
if
it
is,
you
know,
a
sas
scanner
then
put
this
block
of
code
in
it's,
not
something
that's
going
to
be
really
scalable.
E
So
the
generic
report
came
from,
I
think,
james,
in
a
roundabout
way,
but
trying
to
address
this.
How
can
we
allow
each
of
the
scanners
to
provide
the
details
it
needs
without
having
the
front
end
or
the
back
end
having
to
have
really
any
logic
around
it
right
we're
not
making
business
decisions?
It's
just.
We
need
to
give
them
a
repeatable
way
to
display
nicely
formatted
content,
and
so
it's
going
to
be
up
to
the
scanners
to
adopt
and
structure
it.
E
What
andy
has
got
in
the
actually
lindsay
you
want
to
open
the
little
or
hold
on
sorry
nevermind
in
the
list.
These
were
guess.
Components
is
probably
a
good
way
to
to
say
that.
So,
if
you
haven't
looked
deeply
at
the
the
poc
report
format,
it
basically
allows
for
recursive
definition
or
recursive
structure.
So
you
can
make
any
combination
of
the
component
types
to
effectively
output
information.
However,
you
need
and
we're
just
going
to
try
to
display
them
what
andy's
design
has
done.
E
He
has
tried
to
account
for
each
of
those
different
components
with
one
of
these
sections.
I
think
there
was
some
confusion
that
this
is
not
what
any
given
vulnerability
detail
page
will
look
like
this
is
sort
of
a
super
set
of
if
you
just
output,
everything-
and
I
actually
we
chatted
about
this
yesterday-
I
think
he's
going
to
try
to
make
a
an
addition
to
this
page
and
apply
the
component
type
labels
on
each
one
of
the
little
pieces.
Just
so,
it's
really
clear
what
we're
looking
at.
Oh.
A
So
we
have
an
issue
under
this
epic
around
creating
this
schema,
like
I
said,
there's
a
lot
of
this
back-end
work.
That's
already
defined
it
defined,
so
under
the
assumption
that
we've
got
a
schema
that
is
supporting
this
and
we
can
take
a
look
at
that
schema.
If
that's
helpful
today,
if
you
haven't
already,
it
might
take
me
a
little
bit
to
navigate
to
it.
The
goal
is
to
determine
how,
if
we're
moving
forward,
how
to
move
forward
of
this
and
break
down
the
issues.
A
I've
heard
different
things
about
what
what
back-end
work
is
necessary
on
this.
So
me
how
I'm
hoping
that
you're
able
to
help
clarify
some
of
that
for
us
today
or
in
the
or
in
the
near
future
or
savage
today.
Do
we
just
get
data
points
and
then
the
front
end
determines
the
display
of
them,
or
is
there
some
sort
of
transformation
that
generates
the
markup
on
the
back
end
and
delivers
that,
to
the
front
end
as
part
of
an
api
call.
C
Okay,
so,
oh
okay,
so
the
issue
that
we
have
for
the
backhand,
which
is
the
one
magnet
created.
This
is
the
most
flexible
approach
we
can
afford.
C
Yes,
this
one.
This
is
the
most
flexible
approach
we
can
employ
in
the
database
as
we
speak,
because
the
details
column
as
for
as
long
as
it's
adjacent
b,
it
means
we
can
insert
any
value
json
into
that.
A
C
A
Right
and
so
that's
where
I
think
this
proof
of
concept
comes
in,
because
james
actually
has
something
that
was
working
and
he
was
able
to
show
us
with
a
schema
that
he
had
created.
That
is
part
of
this
poc,
the
the
vulnerability
details
page
displaying
all
of
these
different
items.
So
there
is
the
code
behind
all
of
that
in
here.
It's
not
production
ready,
it
doesn't
have
all
the
tests.
A
C
A
A
great
question:
let's
talk
about
that
matt,
I
think
you
might
have
a
better
response
for
that
than
me
kind
of
where
this
ownership
and
how
we
plan
on
having
the
scanner
teams
adhere
to
this.
E
Yes,
so
that's
a
great
question
think
of
this
as
sort
of
net
new.
If
none
of
the
scanners
today
adopt
this,
that's
fine,
this
is
going
to
live
in
or,
I
should
say
it
needs
to
live
in
parallel.
We
need
to
be
able
to
consume
the
current
common
formats
that
each
of
the
scanners
output
and
then
this
new,
unified
schema
type.
E
So
the
long-term
goal
for
this
is,
as
the
scanner
teams
are
able,
they
would
migrate
their
outputs
into
this
new
unified
format,
because
it
gives
them
that
flexibility
to
sort
of
change,
the
information
and
the
presentation
of
the
vulnerability
details
page
as
long
as
they
adhere
to
the
schemas
and
it's
you
know
it's
valid.
We
don't
have
to
do
any
work,
which
is
where
we
want
to
go
on
the
flip
side.
I
see
this
as
being
immediately
useful
for
any
third-party
integrations.
E
We
have
a
limited
number
of
official
integrations
today.
Part
of
it
is
because
it
is
kind
of
a
challenge
as
a
vendor.
I
have
to
first
figure
out
like
okay,
so
I've
got
a
let's
say
a
dynamic
analyzer.
Now
I
have
to
go
to
the
security
documentation.
I
have
to
go
find
the
specific
format,
for
my
specific
analyzer
type
hope
that
it's
got
the
fields
that
I
need
and
it's
not
an
easy
process,
so
this
is
going
to
make
it
a
lot
easier.
E
E
C
Okay,
so
if
we
do
not
want
to
immediately
ask
the
security
to
adopt
the
unified
schema,
then
we
will
have
to
do
some
additional
work
on
the
back
end
to
transform
the
current
schema
employed
by
the
scanners
to
somehow
fit
into
that
unified
schema.
We
just
came
up
with
so
we
will
have
the
old
security
thingy
security
scanners
work
with
no
changes,
and
we
will
have
to
somehow
transform
the
old
input
into
dunya
output
on
the
back
end,
so
we
might
have
additional
work
in
that
case,.
A
And
that's
where
I
think
it
would
help
to
look
at
the
code
behind
this,
because
I
believe
what
you
just
described
is
how
james
approached
that
this
does
currently
support.
Both
the
existing
scanner
schemas
plus
this
new
one
in
parallel,
and
I'm
not
100
sure
about
whether
it
was
doing
a
transformation
or
if
there
was
just
the
dual
code
in
place.
C
A
A
A
Okay,
so
if
the
goal
out
of
this
discussion
is
to
try
to
at
least
determine
the
some
of
the
planning
breakdown,
you
know
I
would
like
to
come
out
of
this
with
a
bullet
pointed
list
of
like
here
is
here,
is
where
the
or
plan
to
do
this
here
is
where
the
front
end
issues
what
they
would
need
to
look
like
and
maybe
hear
some
of
what
the
missing
back-end
issues
would
be
so
savage.
You
would.
B
So
I
remember
the
the
dmr
it
was
a
couple
of
months
ago.
I
checked
yeah,
it
was
a
while
ago.
It's
I
have
some
some
knowledge
on
on
the
topic.
A
So
we
have
this
larger
epic,
which
I
think
is
where
we'd
create
the
sub
issues,
but
I
think
for
right
now
I'll
just
create
a
list
in
the
comments
of
the
design
issue.
A
You
know
the
big
outstanding
question
in
my
head
is
still,
and
I
don't
know
if
it
was
answered
just
now
where
the
styles
are
applied
today.
Is
that
all
done
on
the
front
end
or
is
that
markup
generated
on
the
back
end
today
to
take
the
schema
and
turn
it
into
the
markup
for
the
vulnerability
details
page.
A
That's
what
I
thought,
but
I
wasn't
sure
so,
do
you
have
an
idea
of
where
we
would
start
as
far
as
these
issues
go.
B
So
I
think
first,
we
need
to
understand
what.
So,
if
we
look
at
the
design
that
andy
prepared,
there
are
some
some
fields
there.
We
need
to
understand
which
fields
we
want
to
display
and
probably
create
a
component
for
each
of
them,
so
that
dynamically
they
can
be
displayed
because,
right
today
we
don't
have
these
components,
we
will
so
we
will
need
to
prepare
them.
So
that
will
be
the
first
starting
point,
at
least
for
the
front
end.
E
And
savage
so
when
I
talked
to
andy
about
this,
he
said
he
pretty
much
put
this
together
almost
entirely
with
existing
gitlab
styles
for
things,
so
there
should
be
both
like
the
diff.
That's
an
existing
component
like
on
the
mr
and
many
of
the
other
styles,
or
things
he's
just
pulled
from
our
ui.
So.
B
B
So
probably
we
will
need
some
wrappers
around
to
pass
data
in
it
to
feed
data
in
the
so
components.
That's
my
guess
at
least.
B
But
if
we
have
all
these
components
already
prepared,
that
should
decrease
the
amount
of
work
that
we
need
to
do.
A
So
if
there
were
cases
where
there
wasn't
one,
there
would
be
some
additional
development
there
and
that
would
be
identified
from
this
first
issue
that
or
the
first
bullet
point
that
I
just
wrote
down,
they
seem
pretty
standard.
You
know,
I
don't
think,
there's
anything
that
we're
trying
to
display
here.
That's
really,
you
know
out
of
the
box
new,
but
we
should
leave
the
possibility
open
that
we
might
have
to
put
some
custom
code
around
that.
B
So
the
thing
is,
for
instance,
if
we
have
this
this
component,
I
think
we
will
need
to
work
closely
with
the
back
end
so
that
they
know
what
what
properties
this
component
takes
and
they
need
to
prepare
the
json
accordingly
to
decrease
the
amount
of
work
that
we
needed
to
in
the
in
the
front
end
like
to
map
them
or
to
create
these
wrappers.
So
I
think
the
the
first
bullet
point
identifying
the
the
components
this
can
be
done
together
with
the
beckon.
B
A
And
some
of
this
again
this
goes
back
to
having
the
validation.
So
once
we
do
this
once
and
we,
we
are
confident
that
we've
got
the
right
properties
associated
with
each
element
or
component,
that
there's
validation
in
place
to
make
sure
that
we
don't
have
to
handle
a
whole
bunch
of
weird
edge
cases
of
things
not
being
as
we
expect.
A
And
again,
there's
a
separate
issue
already
today
around
schema
validation.
So
I
think
this
is
just
you
know
during
that
development,
making
sure
that
we've
defined
like
just
to
repeat
what
you
said
that
we've
defined
all
the
properties
that
are
required
to
display
the
element
as
the
design
expects
it,
which
could
result
in
changes
to
what
that
schema
looks
like.
A
A
C
News
I
took
a
look
at
the
like
total
changes
in
the
proof
of
concept.
Merge
request
by
james
and
the
back-end
changes
in
this
proof-of-concept
are
minimal.
He
exposes
two
additional
fields
in
addition
to
what
we
currently
expose
in
the
helper,
which
means
that
this
proof
of
proof
of
concept
consumes
what
we
currently
export
from
the
back
end.
C
But
I'd
like
a
proper
front-end
opinion
on
how
viable
the
code
is,
because
I
I
don't
consider
myself
worst
enough
to
say
this
is
good
code
or
this
gold
is
going
to
require
much
more
work,
but
backhandwise
the
changes
are
minimal.
So
we
could.
This
proof
of
concept
allows
us
to
keep
using
the
existing
schema
without
changing.
A
C
C
C
No
with
regards
to
the
unified
schema
report
schema
what
magmat
did
is
basically
the
most
flexible
approach
we
can
employ
in
this
case,
so
it
makes
perfect
sense
this
one
excellent.
The
question
is:
how
do
we
structure
the
schema
in
a
way
that
it
requires
no
or
minimal
transformations
for
the
front
end
to
display.
A
Yeah,
so
that
goes
back
to
what
we're
trying
to
define
right
now.
So
no
that's
perfect.
So
I'm
great,
that's
great
news.
Thank
you
yeah.
So
what
you
just
described
does
that
make
sense
to
make
a
bullet
point
here,
savage
around
that
transformation,
or
is
that
inherently
part
of
this
first
item
I
think,
do
we
need
a
separate
issue
around.
B
You
got
cut
off.
Can
you
please
repeat
your
question.
A
So
I'm
curious
if
the
transformation
of
the
schema
data
types
to
the
ui
data
types
I
mean
is
that
is
that
handled
here
in
this
first
bullet
point,
or
is
this
just
the
identification
like
we've
identified
that
the
components
are
out
there?
Should
we
have
a
separate
implementation
issue
around
that
transformation
or
mapping.
B
That's
a
good
question,
so
first,
I
think
we
need
yeah.
First,
we
need
to
understand
which
fields
we
want
to
populate.
That's,
that's
the
that's
the
first
step.
The
second
step
will
be
to.
B
B
So
I
was
checking
the
poc
right
now,
the
the
the
front
end
code.
There
are
a
lot
of
front-end
changes
that
it
was
not
what
I
was
expecting.
At
least
it
was
not
what
I
had
in
mind
with
this
with
this
issue,
because
what
I
had
in
mind
was
that
we
have
the
the
the
amount
of
work
that
we
deliver.
It's
mostly
in
the
json,
so
the
json
knows
a
bit,
so
it
provides
also
information
on
the
ui
components.
B
But
what
I
see
here
is
that
we
have
a
lot
of
front-end
code
delivered
that
that
was
not
my
expectation.
So
I
was,
I
was
kind
of
confused,
but
the
thing
is
so
once
we
have
the
json
the
schema
ready,
the
next.
The
next
step
should
be
just
simply
write
those
wrappers
or
if
we
need
any
wrapper,
hopefully
not
which
maps
the
json
to
the
to
the
ui
components.
B
So
that's
that's
the
probably
the
the
second
step,
so
the
first
step
would
be
identifying
the
components
understand
what
we
have
today
and
build
the
json
schema.
According
to
that,
the
second
step
would
be
to
implement
those
those
components,
the
missing
ones
and
the
if
we
have
any
and
then
create
the
mapper,
that's
clear.
I
think
I
was
confused
while
I
spoke
of
it
so.
C
But
my
my
suggestion
for
the
unified
schema
is
that
it's
not
developed
with
the
ui
front-end
consumption
in
mind
that,
because
I
expect,
if
we
do,
that,
having
the
front
end
in
mind
the
unified
schema,
then
I
expect
that
at
some
point
it
would
turn
out
that
people
integrating
tools
with
our
unified
schema
have
a
different
different
requirements
than
the
front-end
has
to
consume
them.
So,
ideally,.
C
With
the
scanners
in
mind
and
structured
in
such
a
way
that
it's
easy
to
write
a
scanner
conforming
to
the
schema,
and
we
would
ingest
that
schema
in
the
back
end
and
we
would
transform
the
input
schema
from
the
scanner
on
the
back
end
transformed
into
a
way
that
can
be
parsed
by
the
front
end
in
an
easy
way.
So,
ideally,
all
the
hard
computation
would
take
place
on
the
back
end
and
we
would
have
a
schema.
That's
designed
with
the
scanners
in
mind,
not
in
not
with
the
front
in
mind.
B
Yeah
you're
right
you're
right.
I
think
the
the
the
ui
logic
shouldn't
sorry.
That
was
my
mistake.
So
what
I?
How
I
imagine
this
is
that
the
back
end
provides,
for
instance,
a
json
schema
could
look
like
this.
There
is
a
type
field,
it
says
diff
and
then
there's
the
data
which
gives
the
div
data,
for
instance,
and
then
we
have
a
mapper
around
it
and
we
once
we
parse
the
json.
We
we
see
that
the
type
whenever
the
type
is
the
diff.
B
We
use
a
diff
component
for
that
and
we
inject
the
data.
So
we
definitely
need
a
mapper
for
that,
but
I
was
imagining
this
to
be
dynamic,
not
like.
I
couldn't
check
the
code
in
detail,
but
I
saw
that
there
was
a
lot
of
front-end
changes.
That
was
not
my
expectation.
My
expectation
was
to
build
a
simple
wrapper,
mapper
function,
which
basically
parses
the
json
data
and
then
displays
the
the
components
in
a
for
loop,
for
instance.
B
E
E
I
think
me
how
your
point
about
making
something
that
scanners
can
output
is,
I
agree,
is
much
more
important
and
then
we're
just
sort
of
allowing
them
to
adjust
the
way
that
they
create
that
output
if
they
would
like
to
see
something
different
in
our
ui
just
sort
of
ordering
of
operations,
but
yes,
avash.
If
you're
seeing
a
lot
of
code
in
a
place
that
you
don't
expect
it
for
the
front
end
stuff,
we
we're
not
we're,
not
we're
not
married
to
that.
We
can
get
rid
of
that
code
and
and
start
from
scratch.
B
Yeah,
I
would,
I
would
need
to
check
in
detail,
because
I
was
I
remember.
I
checked
that
a
few
months
ago
and
then
next
time
I
checked
was
yesterday
and
today
so
I
would
need
to
check
it
in
detail
and
understand
again
what
it
does
exactly.
But
what
I
had
in
mind
was
simply
you
know,
a
function
which
iterates
it
which
parses
the
data
and
then
displays
dynamic
components.
B
So
that
was
maybe
we
can
also
add
it
as
an
issue
to
investigate
the
poc.
That's
that's
something
we
would
like
to
go
ahead
or
exactly.
C
C
The
second
one
would
be
for
front-end
engineers
to
come
up
with
a
desired
schema
of
what
what
what
backhand
should
give
them
to
display
the
report
in
the
vulnerability
details
section
and
the
third
high-level
task
is
to
create
back-end
code
that
would
transform
the
unified
security
scanner
schema
into
the
front-end
schema.
So
that
would
be
three
high-level
tasks
we
currently
have
to
deal
with.
B
Exactly
and
one
thing,
for
instance,
in
the
front-end,
those
components,
the
ones
that
are
written
in
top
of
an
mr
description
are
those
the
ones
that
will
be
used
in
for
displaying
the
the
json
schema.
I
think
there
was.
E
A
list
of
yeah,
so
those
are
the
ones
that
that
james
had
called
out
and
after
I
was
actually
discussing
this
with
him
a
couple
of
months
ago,
like
the
markdown
one
was
one
that
I
thought
would
be
really
helpful
to
add.
So
that's
what's
in
there
now,
if
there
are
certain
things
that
maybe
don't
make
as
much
sense
or
you
think
some
of
the
components
might
be
better
combined
or
split
apart.
That's
open
for
discussion
as
well.
B
Okay,
perfect,
so
what
I
would
do,
for
instance
here
I
would
go
one
by
one
through
this
list,
understand
what
data
these
components
require
and
then
build
or
ask
the
backend
to
provide
the
the
the
specific
data
based
on
that.
So
so
it's
it's
in
line
with
what
meehau
said.
First,
the
back
end
creates
defines
the
the
json
the
the
fields
that
that
are
needed.
Then
we
collaborate
with
the
back
end.
We
tell
them
what
kind
of
data
and
we
need,
and
then
we
start
building
it.
B
I
think
the
the
bulk,
the
the
great
amount
of
work
here
is,
is
on
on
creating
the
json
schema.
The
rest,
I
hope,
should
be
just
some.
A
A
It
sounds
like
we
need
to
create
an
another
one
for
the
front.
End
display
schema
based
on
what
you're
saying.
Is
that
correct.
B
I'm
not
sure
if
we
need
a
schema,
we
just
need
a
mapper,
so
we
need
to
parse
the
json
and
then
we,
since
this
is
going
to
be
dynamic,
we
need
a
for
loop,
probably
which
iterates
through
the
fields
and
then
displays
what
component
we
need.
So
so.
A
This
really
did
kind
of
capture
it
before
this.
What
we
said
previously,
this
is
really
the
front
end.
What
you're
describing
here
yeah
exactly
exactly
okay,
I
don't
think
the
transformation
that
you
described
me
how
has
already
been
captured.
C
So,
ideally,
what
I
had
in
mind
is
that
front-end
engineers
initiatives
come
up
with
a
desired
json.
They
get
from
the
back
end.
C
A
And
that's
a
good
point
getting
input
from
others.
Insecure
will
definitely
be
a
step,
keep
in
mind
since
we're
gonna
continue
to
support
the
existing
schemas,
we're
not
asking
them
to
change
anything
right
away.
We
should
make
it
as
compatible
so
that
they
would
want
to
adopt
the
schema
as
possible
and
make
whatever
plans
for
that
early.
A
C
Yes
collaborative
if,
if
we
follow
this,
then
there
will
be
one
additional
backend
task,
which
is
basically
transforming
the
details:
json
b
column
from
the
unified
input,
unified
scanner,
unified
scanner
schema
to
the
schema
desired
by
the
front-end
team.
So
we
will
have
one
additional
issue
for
the
back-end.
A
B
Ahead,
while
it's
it's
a
backhand
issue
to
create
the
json
schema,
I
think
we
need
to
collaborate
closely
with
the
so
it's
also
front
and
issue,
because
we
need
to
specify,
as
mija
said,
we
need
to
specify
what
fields
we
need.
B
C
C
C
A
I
think
this
might
be
a
separate
issue,
then
so
you're
talking
about
there's
the
generic
security
report
schema,
and
this
is
the
one
that
we
want
the
secure
team
to
agree
on.
Yes,
yes
is
the
schema
that
you're
talking
about
now
the
front-end
schema.
That's
expected.
Do
we
need
a
second
issue
around
that
front-end
schema.
C
B
I
I
think
linsey
it's
like
this,
so
there
is
the
defined
json
schema.
I
think
that's
that's
breakdown
yeah!
The
first
one
is
that
the
front-end
does
the
investigation
and
tell
the
back-end
what
fields
they
want.
Yeah
correct
me
if,
if
I'm
wrong
and
then,
which
is
a
blocker
for
the
back
end
issue,
to
create
the
json,
so
first
the
the
backend
needs
input
from
the
front
end
so
that
they
can
start
writing
the
json
schema.
I
think
that's,
okay,
that
makes
sense.
C
C
C
A
C
That
captures
the
idea.
Okay,
I
mean
we
will
be
just
transforming
the
one
one
from
one
schema
to
the
other
schema
and
in
the
process
we
will
get
two
different
schemas,
but
one
is
optimized
towards
integrating
new
scanners
and
the
second
one
will
be
optimized
towards
front-end
display.
A
A
C
A
C
B
Do
I
understand
this
correctly,
so
you
will
have
one
schema
for
for
the
back
end
and
then
you
will
have
something
that
transforms
that
schema
into
what
the
front-end
desires
exactly
and
you
will
send,
and
you
will
send
that
back
to
us
yeah,
okay,
so
we,
the
front-end,
will
never
know
about
the
schema.
That
is
in
the
back
end
the
the
one
that.
C
B
C
Shouldn't
right
yeah,
ideally,
you
shouldn't
know
any
details
about
the
scanner
schema,
because
if
we
force
you
to
consume
the
scanner
schema,
then
we
will
create
a
like
dependency
between
what
frontend
expects
and
what
the
scanner
should
provide.
While
I
think
that
the
scanner
schema
should
be
geared
towards
integrating
new
scanners
and
the
frontend
schema
should
be
different
and
it
shouldn't
depend
on
what
scanners
provide
okay.
B
That's
the
data
structure
yeah
I
so
you
will
store
the
raw
data.
For
instance,
let's
put,
let's
call
it
the
raw
data
in
the
database,
the
ones
that
generated
from
the
from
the
scanners
and
then
once
the
front-end
asks
it.
You
will
take
that
data,
you
will
massage
it
and
then
you
will
serve
it
to
us
right.
So
that's
why
you.
B
A
C
B
Okay,
I
thought
that
you
would
store
into
the
database
the
one
that
will
be
served
to
the
front
end,
but
that's
not
gonna.
That's
not
gonna,
be
the
case.
C
B
A
A
C
A
I
feel
like
we're
missing
something
in
the
front
end
and
developing,
and
maybe
that's
this
savage
developing.
What
that
display
schema
looks
like
would
that
be
represented
by
this
item
that
I
have
highlighted
here.
A
B
I
I
like
the
terms
you
use
the
generic
report
and
then
the
display
report
or
the
display
the
generic
scheme
and
then
the
display
scheme.
So
maybe
the
first
one
is
the
generic
scheme
and
then
the
second
one
identify
get
live.
Ui
component,
the
one
the
second
bullet
point:
it's
it
it's
the
display
scheme,
which
mihaw
was
mentioning
like
the
ones
that
that's
gonna
be
served
to
the
frontend.
A
A
I
was
having
this
conversation
with
someone
yesterday,
okay,
so
the
number
the
first
one
the
generic
report
schema,
is
what
we're
talking
about
here.
The
the.
E
A
B
A
B
B
So
one
should
be
defined
in
the
schema.
The
other
issue
should
be
implement.
The
schema
yeah,
yes,
but
also
in
the
front
end
implement
parse
that
schema
into
ui
components.
So
one
is
give
the
backend
what
they
want
so
that
they
can
prepare
the
schema
and
then
the
second
one
is
parsing
it
in
the
front
end.
So
we
we
have
two
front-end
issues.
A
Okay,
so
I
currently
see
the
need
for
three
more
issues
or
three
new
issues
around
the
front
end
of
finding
the
display
schema
the
back
end
developing
that
display
schema
right,
generating
it.
B
Chronologically
the
first
one
should
be
defined,
json
schema,
the
second
one
should
be
front-end
defined,
vulnerability
to
the
details,
display,
schema
and
then
the
third
one
should
be
back
and
generate
the
expected
vulnerability.
Details
display,
schema
and
then
the
fourth
one
should
be
front
end.
I
don't
know
okay.
A
A
I
feel
like
this
is
something
that
we'll
probably
need
to
break
down
a
lot
more,
especially
given
some
of
the
more
complicated
like
the
diff
component,
and
things
like
that.
That
might
be
harder
to
develop
like
that.
Could
that
be.
C
A
A
Let's
start
it
as
an
issue,
we
can
convert
it
to
an
epic
as
we
go
through
again
that
limitation
of
five
epochs
we've
hit
that
a
lot,
especially
if
you
look
at
the
hierarchy
of
like
the
maturity
definition
epics.
This
could
turn
into
an
epic.
A
That's
that's
a
thought
too.
So
that
can
be
part
of
the
refinements.
You
know,
I
don't
think
we
need
to
decide
that
here.
So
can
we
think
of
anything
else
that
we
and
I'm
happy
to
create
these
implementation
issues,
but
I'm
going
to
sign
them
off
to
you
guys
for
refinement
and
putting
more
details
on
them.
I've
already
asked
savash
to
create
a
lot
of
implementation
issues
in
a
different
area,
so
I
don't
want
to
pile
this
all
on
him.
Is
there
anything
else
that
you
guys
can
think
of,
though.
B
So
the
only
thing
that
I
would
change
here
is
that
the
front-end
identify
gitlab
ui
component.
I
think
the
identification
process
goes
into
the
second
issue.
This
one
is
just
in
the
implementation
of
the
mapper.
B
Yeah,
maybe
you
can
just
remove
that
as
well.
Working
with
vanishing
expert
person
jason,
I.
A
B
A
A
So
if
anyone
else
wants
any
insight
into
how
we
got
to
these,
my
hope
was
to
be
able
to
loop
back
around
and
put
some
notes
in
the
agenda,
but
I
think,
since
we've
created
this
list
of
issues,
that's
kind
of
that
was
my
goal
of
this
discussion,
so
I
succeeded.
A
Or
I
always
like
confused,
that's
just
that's
just
me,
I'm
not
confused.
I
feel
I
was
expecting
there
to
be
a
lot
more
issues
coming
out
of
this,
but
I
think
that
this
is
really
where
they
live
and
I
think
that'll
come
out
of
some
of
this
refinement,
so
I'm
not
confused.
I
just
want
to
make
sure
that
you
guys
are
comfortable
with
this.
I
mean.
C
This
makes
sense
to
me
as
well.
What
I'm
unsure
is
whether
we
need
a
synchronous
meeting
with
secure
team,
or
we
can
do
that
asynchronously,
but
yeah.
That's
up
for
the
debate.
A
A
The
thing
that
we
want
to
make
really
clear
to
everyone:
we
don't
want
to
cause
confusion,
saying
that
they're
going
to
need
to
make
updates
right
away
to
use
this
schema.
You
know
we're
not
asking
anyone
to
change
their
their
current
schemas.
We
just
want
to
make
sure
that
we're
building
something
that
will
meet
their
needs.
If
they
do
decide,
I
mean
they.
Who
knows.
One
of
these
scanners
could
decide
that
they
want
to
embrace
one
of
these
new
elements,
and
then
we
say:
hey
you
got
to
switch
over
and
use
the
generic
report
schema.