►
From YouTube: Secure Team: Group-level Security Dashboard - Part II
Description
Discuss the API for the Security Dashboard at the group level.
This meeting was to discuss and validate the final contract between backend and frontend. More info: https://gitlab.com/gitlab-org/gitlab-ee/issues/6709
C
Thing
is
because
the
interface
is
split,
just
a
reminder:
it
split
between
those
two
sections
that
added
up
it
split
between
those
two
sections,
so
I
thought
we
go
with
two
API
endpoints.
It
also
has
the
benefit
that
we
could
ask
use
the
summary
endpoint
to
to
find
out
if
we
even
need
to
do
the
other
requests.
You
know
because
we
have
to
somehow
to
take
the
empty
state.
C
So
what
I
just
would
do
and
I
think
the
summary
is
not
the
most
controversial
it
would
just
be
asking
for
the
summary
of
a
group
say
I,
just
named
it
security
dashboard.
This
is
obviously
I
have
already
pasted
the
links.
This
is
obviously
we
can
change.
It
doesn't
need
to
be
named
security
dashboard,
but
then
it
just
returns
and
JSON
object,
which
has
a
total
integer
and
then
it's
by
severity
and
by
type.
C
Okay
and
you
yeah
I
mean
if
it
would
be
in
the
public
API
it
could
be
under
the
group.
You
know
that
it
maybe
it
is
like
group
and
then
I,
don't
know
whatever
so
I,
don't
want
to
bother
with
the
name
but
I
think
the
what
we
can
send
and
what
we
receive
is
more
important,
and
this
endpoint
is
infamous
Ari.
This
endpoint
is
the
boring
one
and
I
think
it
makes
more
sense
to
talk
about
the
other
one.
As
I
said,
the
Antoine
name
here
is
a
bit
unclear.
C
C
C
As
a
result,
it
would
be
Jason
array
and
adjacent
array
of
objects,
so
I
just
called
them
vulnerability
from
the
typhoon,
ability
and
vulnerability
will
be
basically
the
name.
The
thing
we
display
as
the
name
type
again
severity
confidence.
Whether
the
thing
is
dismissed
or
not,
then
the
body-
and
maybe
we
didn't
rename
it
buddy-buddy.
It
would
be
the
JSON
blob
we
have
in
a
database
I,
don't
know
if
there's
a
better
name
for
it
and
then
I
would
like
to
add
a
project
object,
because
in
the
front-end
we
have
no
information
about
the
project.
C
Id
namespace
that,
while
the
vulnerability
feedback,
where
all
the
issues
where
all
if
you
want
to
fight
issues
and
metadata
is
maybe
good.
Yes,
so
I
think
these
are
all
the
things
you
store
in
the
database.
Of
course,
if
there
are
more
fields,
just
expose
them
here
as
well,
we
may
use
them
in
the
future
and
otherwise
yeah
so
Olivier
edit
category
or
to
be
discussed
in
the
front-end
pick
out.
We
always
call
it
reports
type
or
we.
D
C
And
actually
I
don't
care
about
the
names
of
the
fields.
It's
just
like
all
the
fields
should
be
there
and
I
mean
it's.
The
and
probably
the
thing
we
would
forget
is
that
we
need
project
object,
the
because
I
looked
again
and
the
vulnerability
feedback
URL
is
based
on
the
project,
so
we
should
have
a
project
object
and
have
the
ID
in
there
and
everything
we
need
to
link
something.
D
You're
missing
or
so
information
about
feedback,
because
you
want
to
know
if
she's
dismissed,
so
you
have
the
boolean
right,
but
you
need
also
to
know
who
dismiss
that
which
pipeline
is
it
eventually
if
it
has
created
created
issues?
What's
the
number
of
these
issues
to
generate
the
link?
I,
don't
remember
if
it
just
been
give
you
the
link
already
so.
E
D
E
C
D
C
D
D
The
the
current
code,
you
eventually
would
have
to
rebuild
a
small
and
there's
a
mutation
in
the
mutation
metal.
You
will
have
to
do
a
small
mapping,
but
if
you
want
to
provide
a
pin
API
right
now
without
we
have
to
get
rid
of
this
JSON
object
because
it
will.
It
may
change
between
different
version
of
the
reports,
and
we
want
to
avoid
to
expose
this
different
version.
We
will
normalize
that
on
the
backend
side
and
West
provide
you
a
come
on
API
on
on
the
front
end.
So
do.
D
So
anywhere
standardized,
if
you
look
at
the
YouTube,
the
gs5
I
already
changed
a
lot
of
the
code
to
make
them
really
compatible
with
the
common
report
format
we
have,
which
is
the
one
is
used
by
SAS.
So
if
you
look
at
parses
and
press
the
parentheses,
there
is
already
backward
compatibility,
stuff
and
still
alot,
so
I
may
be
wrong.
But
to
me
the
only
thing
we
have
to
do
is
eventually
do
a
small
mapping
between
the
property.
D
C
So,
but
it's
there
I
mean
you
work
now
on
last.
The
problem
is
what
I,
what
I,
personally
really
don't
like,
is
if
you
have
a
flat
list
of
flat
objects
and
those
objects
are
of
different
types,
I
mean
inheritance
right,
so
what
I?
Actually
what
I
like
more
is,
if
you
have
a
type
property
and
you
if
you
ever
have
to
do
something
differently
because
of
the
dot
type
or
category
or
what's
not,
I
like
to
have
all
the
properties
that
belong
to
the
category
in
a
sub
object?
It's
just
personal
thing:
I.
D
C
Okay,
well
because
all
the
things
in
the
model,
as
far
as
I
remember
the
front
end
code
correctly,
basically
just
iterate
over
the
object
and
show
you
every
field.
We
have
a
definition
for
basically
and
so
yeah.
Maybe
it
makes
sense,
you
know,
and
some
I
don't
know
we
could
throw
everything
in
your
flat.
But
there's
always
the
problem
with
conflicts
or
something
I
don't
know
in
the
future.
And
if.
D
You
put
it
in
the
in
the
flat
up
if
I
in
the
top
level
from
the
ncip
ax,
it
means
that
we
are
able
to
normalize
that
on
the
on
the
decking.
Otherwise
it
has
to
be
if
it's
I
mean
if
it's
the
same
property
name,
but
the
value
is
to
tell
you
different
I,
don't
know.
Sometimes
you
just
have
a
string,
and
sometimes
you
have
an
object.
We
won't
do
that
in
the
same
property.
B
D
This
is
clearly
only
for
that,
so
we
could
have
this
conversation
to
decide
whether
we
just
put
it
on
the
on
the
top
level
and
for
type
of
vulnerabilities
at
image.
We
just
don't
have
the
property
or
it's
an
empty
array,
so
you
have
a
really
common
behavior
for
all
kind
of
vulnerabilities
or
we
can
go
for
more
type
of
objects
so
that
you
can
more
type
at
front-end
and
Ling
and
we
can
also
leverage
of
specificity
to
have
specific
components
that
will
leverage
those
properties.
We
already.
C
Have
those
some
things
and
the
question
also
is:
we
yesterday
talked
about
making
the
information
public
and,
in
my
opinion,
if
someone
wants
to
build
something
on
the
public
API
for
them,
the
raw
data
will
be
beneficial.
I
mean
it's
okay
to
have
like
standardized
things,
but
I
think
we
can
all
agree
that
those
standardized
things
will
always
be
less
than
all
the
other
information
we
have
right
and
so
I
don't
know,
because
everything
else
on
the
public
API
is
properly
defined,
I,
don't
know
how
we
would
handle.
D
D
A
C
D
C
E
A
No
I
mean
I
like
the
intern,
but
everything
is,
as
we
can
said,
it's
if
you
want
to
normalize
everything.
It's
gonna
be
less
than
the
specific
Oh
dad
I
we
can
get
from
one
specific
analyzer,
but
oh
yeah
I
wanted
to
go
back
to
a
previous
point.
So,
okay
from
what
I
understand
you
want
to
standardize
the
output
right
away
and
get
rid
of
this
body.
Slash
meter
data
field
right
from
the
beginning
and
yeah.
D
D
A
Sure
that
there
is
no
extra
cost
in
doing
that,
because
the
the
intent
when
suggesting
this
body
or
meter
da
fiel
or
:
actually
in
the
days
was
to
make
the
transition
easier.
Since
we
already
have
it
all
the
card
in
the
front
and
tool
of
that
beast
information
automatically
in
the
model
without
so
yeah,
the
intent
was
to
to
make
sure
that
we
wouldn't
there
would
mean
no
need
to
change
the
from
town
Oh,
at
least
at
the
beginning.
D
The
thing
is
that
we
were
doing
that.
We
will
be
doing
that
for
artifact,
passing
for
match,
request
and
pipeline
view.
We
don't
average
the
data
rates,
but
we
want
to
have
a
back-end
person.
So
if
we
do
that,
we
don't
have
any
choice
to
just
pass
through
the
JSON
to
the
front-end
and
since
the
front-end
is
rewritten
all
those
sections.
But
today
we
are
working
on
the
group
dashboard,
which
is
a
brand
new
page.
A
D
C
I
mean
I,
have
dependency,
dependency
scanning
and
I
had
information
in
there
which
dependency
or
whatnot,
and
that's
maybe
different
from
you
know,
in
Java,
apps
from
the
class
or
yeah
I
mean
it's
also
a
good
example.
If
you
have
a
code
project
that
has
JavaScript
and
has
Java
code,
it
will
have
things
like
classes
on
the
one
hand,
and
we'll
have
other
Zod's
that
don't
have
classes
so
I,
don't
know
I
mean
in
the
in
the
new
stuff
people
here
in
the
front
end
I
just
want
to
rely
on
the
on
the
information.
C
Api
has
on
a
top
level,
but
for
them
for
these
models,
for
example,
or
for
these
for
for
yeah
up
for
these
models,
for
example,
I
it's
okay
to
rely
on
the
JSON
blob
we
have-
and
maybe
you
can
later
on.
You
can
also
start
normalizing
the
things
we
have
in
a
JSON
blob
right,
I,
don't
know
yeah,
that's
my
part,
yeah
I.
C
A
For
me,
the
idea
is
to
rely
on
what
we've
got
right
now
in
the
frontier.
So
if
there's
a
way
it
doesn't
have
to
be,
it
doesn't
have
to
be
part
of
what's
returned
by
this
different
rainbow
in
actually
yeah
I'll
talk
about
that
later,
but
yeah.
The
idea
was
to
reuse
most
of
the
existing
code.
So
if
the
data
is
the
same
I
guess
the
front-end
code
is
to
say
the
model
and
the
JavaScript
code
it
will
I
am
but.
D
D
What
we
do
is
that
we
are
processing
the
report
already
normalizing
data
and
then
we
fit
it
to
the
model
and
I
I
worked
on
this
front
end
product
and
I
made
things
really
close
to
what
is
what
is
a
common
format
right
now,
so,
okay,
we
can
go
this
way,
but
I
mean
it
will
be
a
waste
of
time,
because
we
are
really
so
close
to
the
final
results
that
it
will
be
just
few
adjustments
to
map
these
vulnerabilities.
New
vulnerability
object
to
what
we
need
to
feed
to
the
model
store.
C
C
Be
really
really
annoying
I
mean
we
don't
do
that
right
now,
so
we
have
to
write
more
code
for
the
query.
It's
fine,
because
if
you
open
the
model,
you
query
for
it,
but
will
mean
more
adjustments
and
maybe
not
MVC,
because
at
the
moment
the
moment
you
don't
have
T.
You
also
don't
have
like
an
endpoint
available
where
you
have
the
artifact
for
specific
vulnerability.
Right
would
also
mean
that
you
have
to
build,
add
additional
back-end
endpoint
instead
of
just
taking
the
Jason
field
in
there,
yeah.
A
C
So
but
the
problem
to
me
is
I,
because
we
are
talking
about
the
clean,
API
and
I
thought.
It
may
be
more
useful
to
put
all
that
stuff
in
a
different
object,
because
right
now,
right
now,
I'm
looking
in
the
in
the
source
code
and
we
have
subscription
identifiers
as
fire
class,
name
method,
name,
namespace,
severity,
confident
solution,
links
and
instances.
These
are
the
fields
we
show
in
the
model
and
I
think
we
show
additional
stuff.
D
E
D
Will
be
the
same
work
to
map
this
to
the
existing
model?
Store
it's
just
a
matter
of
okay.
I
want
this
property
I
just
go,
find
it
in
that
sub
object
instead
of
this
top
level
property.
So
to
me,
it's
just
a
just
a
quick
mapping.
It's
really
easy
to
work,
but
if
you
want
to
discuss
if
we
were,
if
we
have
to
put
specific
properties
into
a
sub
object,
I'm
fine
with
that.
But
the
issue
is,
we
didn't,
have
done
right
now
enough
research,
the
other
kind
of
report.
D
Yeah
I
won't
be
able
to
decide
right
now
to
me,
but
based
on
what
I've
worked
on
by
the
work
I've
done
on
the
metadata
to
me,
we
can
have
just
flat
objects
but,
as
you
say,
it
could
be
better
sometime
to
have
type
of
component
in
the
front
end
and
elaborate
just
different
things,
using
an
extra
object
or
even
for
readability.
I
don't
know,
yes,.
A
C
D
D
C
D
D
D
C
C
C
C
D
D
E
C
D
E
C
C
A
C
C
C
D
C
E
E
C
Yeah
so,
and
that
that
list
will
hopefully
give
us
the
project
ID
should
make
sense,
yeah
I
hope
we
have
a
component
for
that
other.
Maybe
we
have
to
put
that
further.
I
mean
it's
good
if
we
have
to
further
than
the
ABI,
and
if
that
drop-down
takes
too
long,
we
can
maybe
move
it
out
of
the
MVC.
We'd
still
have
to
check
that
I'm
going
to
write
down
that
Christian
I
mean
there's
a
nice,
the
nice
thing
about
the
severity
and
confidence
they
will
be
fixed
values
right.
D
E
D
C
C
C
D
D
C
D
E
D
D
C
D
C
D
D
But
that's
weird
this:
these
are
really
not
useful
for
severity.
This
is
what
I
was
telling
you
that
we
are
currently
using
the
same
set
of
values
for
both
properties,
but
some
doesn't
make
sense.
So
it's
a
technical
way
to
it
to
make
it
easier,
but
to
me
it
doesn't
make
sense
to
provide
those
values.
At
least
it's
not
a
big
deal,
because
here
is
just
a
list
of
possible
values.
Even
if
you
don't
have
it,
it's
not
a
big
deal,
but
for
the
features
the
Kelly's
don't
make
sense
to
have
them
for
480
anyway,.
C
Have
a
different
text
value
in
there,
you
may
not
get
I
just
have
to
think
about.
Okay,
if
I
get
ignore
and
I
don't
have
the
style
for
ignore,
like
the
red
green,
whatever
you
will
just
have
it
in
a
box,
and
there
will
be
the
word
ignore
so
I
have
to
have
an
Elk's
or
default
in
the
switch
statement
right,
yeah,
okay,.
C
D
To
me
it
won't
be,
it
will
necessary.
Challenge
is
an
object,
and
unless
you
really
asked
for
it,
I
wouldn't
have
it.
We
could
have
an
extra
or
metadata
fields
that
will
provide
type
specific
properties.
If
we
want
to
go
that
route,
and
it
seems
that
this
is
what
we
want.
According
to
recent
discussion
yeah,
so
here.
D
B
D
C
E
We
have
a
ten
minutes
left
there.
The
only
concern
that
I
have
is
the
the
the
sake
of
scalability,
because
I
can
see
that
being
used
later
for
the
project
as
board
as
well.
So
it
should,
you
know,
be
the
same
objects
that
we
will
have
in
the
project
dashboard
and
the
group
level
dashboard
and
the
instance
level
dashboard.
Just
you
know,
grouped
by
different
levels,
so
just
want
to
make
sure
that
we
will
be
able
to
do
that.
E
C
I
mean
I
mean
if
we
go
one
level
up
here.
You
could
also
think
everything
like
by
group
or
something
and
additionally
in
that
object
at
a
group
object
or
something
I,
don't
know
really
the
I
mean
once
we
see
real-life
examples
and
real-life
groups.
We
will
know
I
have
a
better
idea
how
to
aggregate
all
the
things
on
a
instance
level
yeah
for.
B
E
C
E
C
D
E
D
E
C
D
The
post
gets,
it
should
be
I,
think
more
about
rest
style,
so
about
specifying
the
resource
we
are
getting.
So
maybe
a
more
like
your
abilities,
because
I'm
pretty
sure
we
won't
want
to
explore
things
like
as
occurrences.
Even
if
there
are
occurrences
I
know.
That's
it's
not
a
well
appreciate
world
for
these
are
facing
yet
so
it.
A
D
C
D
C
C
D
E
A
D
E
And
I
think
we
will
have
the
same
meeting.
Look
as
if
you
agree
on
the
license
management
on
Monday,
would
you
bet
yeah?
No,
no
worries
sounds
really
necessary
to
make
sure
that
we're
all
on
the
same
page,
and
this
is
really
productive.
I'm,
not
sure
we
will
have
to
spend
one
hour
like
this,
because
this
one
is
a
big
subject
compared
to
license
management.
Yeah
30
minutes
would
be
fine.
Thank
you.
Yeah.