►
Description
Includes a demo at the beginning of the current state of first-class vulnerabilities: https://gitlab.com/gitlab-org/gitlab/issues/13561
B
Sam,
we
can't
hear
you
I
forgot
to
unmute
my
actual
microphone
good
start
right.
So
this
is
a
demo
of
the
vulnerability
list.
It's
unmerged
quarter
still
need
to
write
tests
for
it,
but
I
figured
it's
best
to
show
people
now
and
get
and
get
some
feedback
on
where
I
am
with
it.
Let
me
just
share
my
screen:
okay,
so
I'll
actually
I
just
enable
the
feature
flag.
So
without
the
feature
flag,
we
can't
see
the
page,
which
is
exactly
what
we
would
expect
with
the
feature
flag
when
the
page
reloads.
B
B
Okay
right,
so
we
have
the
the
vulnerability
list
inside
the
security
and
compliance
navigation,
which
renders
unsurprisingly
a
vulnerability
list.
This
is
just
really
simple
done
in
Hamill.
This
list
will
eventually
disappear
when
we
get
the
actual
thing
in
and
we'll
be
using
the
dashboard.
But
for
now,
when
we've
got
the
feature
flag
on
this
is
where
we
get
a
list
of
all
the
vulnerabilities,
the
actual
first-class
vulnerabilities.
So
we
get
the
stair.
It's
a
very
the
description
and
title
now.
B
This
is
its
dummy
data,
but
the
templates
rendering
correctly
I've
just
generated
the
same
vulnerability
several
times,
which
is
why
it
looks
a
bit
weird
and
it's
all
paginate
and
everything
and
clicking
through
it,
get
you
to
the
first-class
one
ability
page
that
we
we
showed
before
so
now.
We're
I
believe
Ross
has
pushed
the
thing
that
automatically
creates
first-class
vulnerabilities
on
the
the
default
branch.
I
could
be
wrong,
but
I'm
pretty
sure,
that's
in
now,
so
now
we
get
them.
B
We
get
a
list
of
them
and
we
can
go
through
them,
so
we
can
really
start
playing
with
them
now.
I
do
have
one
question
myself
that
just
goes
to
the
room,
I
guess
before
anyone
else
jumps
in,
and
that
is
with
the
routing.
So
the
actual
vulnerabilities
are
at
security.
Slash
vulnerabilities,
that's
where
the
vulnerability
list
is
but
clicking
through
to
a
vulnerability
is
currently
security.
/
dashboard,
slash
vulnerability,
ID.
B
This
is
how
we
set
it
up
originally,
but
now
that
I'm
actually
using
it
I'm
thinking,
maybe
this
is
this-
is
wrong
and
it
should
be
Security's
fashion
for
abilities,
slash
ID,
which
means
we
need
to
change
a
couple
of
its
in
the
controller's,
but
nothing
too
nothing
too
hard
right,
now,
probably
harder
later
on
I,
just
kind
of
want
to
get
people's
thoughts
on
that
one,
but
yeah
there.
We
have
one
a
really
list,
any
thoughts
on
what
I've
just
asked
or
questions
about
what
I've
just
shown.
A
Forgive
me
for
asking
this
question
and
I
will
go
ahead
and
duck
or
accept
slap
to
the
back
of
the
head
in
progress,
something
everybody
is
here
for
asking
this
win
this
ships
and
I'm,
not
saying
if
I'm
saying
win
this
ships
and
we've
turned
this
fleet,
your
feature
flag
off
and
it
goes
away.
Where
does
this
whole
feature?
Live,
doesn't
live
at
dashboard?
Where
does
lipid
phoner
abilities.
B
So
that's
that's
the
reason
that
this
link
is
currently
security,
/
dashboard,
slash
vulnerability,
ID,
because
the
idea
is
to
have
the
vulnerabilities
listed
on
the
dashboard
rather
than
a
separate
vulnerability
list.
This
is
just
so
it's
easier
to
keep
them
separate
for
now,
but
I
think
even
still
the
URA,
so
this
URL
makes
it
seem
like
it's
the
seventeenth
dashboard,
rather
than
the
seventeenth
burner
ability
yeah
having
the
dashboard,
is
the
list
and
was
the
reason
why
this
URL
was
originally
chosen.
Book
I
figured.
C
B
D
D
A
D
A
D
So
so
a
look.
There
is
a
little
bit
of
deduplication
because
we
have
like
a
location
fingerprint,
so
we
won't
like
recreate
a
vulnerability
that
we
already
know
about
and
can
find
based
on
that
location
fingerprint,
which
is
no
line
of
code
in
a
file.
Essentially,
but
you
know
we
still
have
the
existing
problem
of.
We
can
lose
track
of
a
vulnerability
if
it
moves
down
lines
or
whatever,
but
that,
like
that's
an
existing
problem,
that
we
have
that
that's
not
addressed.
D
C
All
right
cool,
so
this
is
probably
a
thought
that
should
have
occurred
to
me
much
earlier,
but
I
realize
so
now
that
we
have
our
first
official
posted
security
integration,
partner,
white
source
we
announced
a
couple
of
weeks
ago.
They
have
built
their
integration
on
top
of
our
current
model,
what
is
going
to
happen
to
them
or
anyone
that's
chosen
to
make
their
own
integration
when
we
make
this
cut
over.
C
Is
that
even
a
question
that
we
can
answer
right
now
and
kind
of
extending
that
out?
So
let's
say
that
we
do
realize
that
there
is
going
to
be
a
potential
issue
for
them.
As
a
more
general
question,
how
can
we
make
changes
like
this?
Where
we've
got
a
feature
flag
and
we're
going
to
flip
it
on
and
have
vendors
kind
of
come
along
with
us?
Is
the
I
think
it's
kind
of
the
gem
of
the
more
general
question
is
that
well
let
start
with
that.
First,
one:
what's
gonna
happen
to
white
source?
C
They
are
hooking
in
to
the
pipeline.
They
are
generating.
The
json
reports
for
can't
forget
what
they
do.
Dependency
is
one
of
them,
so
they're,
basically
overwriting,
where
are
included
our
default
scanners,
replace
the
json
reports.
It
looks
like
they're
also
creating
an
issue.
Now,
that's
their
own
little
I,
guess
secret
sauce
that
they
made
as
part
of
the
integration.
C
A
Gonna
naively
assert
something
that
let
people
tell
me
where
I'm
wrong
since
they're,
just
replacing
the
analyzer
and
are
creating
the
JSON
report.
It's
going
to
be
akin
to
creating
findings
which
should
then
be
promoted
to
vulnerabilities
by
the
new
system,
since
they
are
creating
issues
as
well.
What
they
will
not
have
is
the
linkage
between
the
promoted.
D
C
C
Yeah
as
long
as
they're,
creating
the
vulnerability
objects
and
they're
also
still
separately,
creating
their
issues
and
I,
don't
think
we've
made
anything
broken
necessarily
not
to
mention
the
issue.
Creation
was
something
that
they
decided
to
do
on
their
own.
That's
not
necessarily
something
that
we
want
to
encourage
in
the
future.
We
didn't
have
a
better
option
for
them,
so
I
think
it's
gonna
require
a
little
bit
of
rework,
but
my
hope
is
that
they
can
do
the
rework
around
the
time
that
the
feature
flag
comes
off.
C
D
C
Thing
yeah
I
had
actually
asked
them
several
weeks
back
for
a
test
environment
or
a
test
project
where
they
had
their
stuff
set
up
and
I,
don't
think
they
had
anything
at
the
time
and
it
kind
of
fell
off
the
radar
because
it
wasn't
that
important,
but
let
me
reach
out
to
them
and
what
would
be
required
from
your
end?
Do
you
just
need
I
guess,
access
to
an
environment
with
their
integration
running.
C
D
C
Sure
they
actually
made
it
about
three
minute
long
demo,
video
of
what
they
were
actually
doing.
I
mean
they're,
just
kind
of
showing
you
visually
the
flow.
So
let
me
share
that
yeah
here
in
just
a
second
and
then
I
can
reach
out
to
them
and
figure
out
whatever
we
need
to
kind
of
work
with
them
to
see.
If
it's
kind
of
just
gonna
be
a
little
bit
weird
or
it's
gonna
break
anything
yeah.
E
I
think
we
should
be
clear
to
them
that
we
don't
want.
Unless
we
do,
we
don't
want
vendors,
creating
an
issue.
Every
time
we
vulnerabilities
detected.
We
want
vendors
to
follow
the
model
that
we're
creating
today,
so
I,
don't
think
we
need
to
bend
over
backwards
and
like
kind
of
accommodate
what
they've
already
built,
because
they've
kind
of
just
like
hacked
it
together.
Oh
yeah,.
C
C
C
Well-
and
maybe
this
is
the
wrong
way
to
think
about
it
when
we
were
talking
it
through
it,
just
it
sounds
like
they're.
Really,
the
only
difference
between
the
finding
and
the
vulnerability
is
the
question
of
persistence
and
so
I
think
we're.
We
we've
been
getting
a
little
bit
wrapped
around
the
semantics
of
it,
sometimes
that,
ultimately,
there's
gonna
be
things
that
are
like
well,
no,
though,
we'll
be
false
positives,
we
know
there
were
going
to
be
things
that
are
potentially
legitimate
issues
that
we
that
the
you
know
the
user
just
says.
C
You
know
what
that
vulnerability
type
doesn't
apply
to
me
because
I'm
not
using
it
at
my
product,
whatever
that
that
persistence
may
be
important
for
things
like
so
we
thought
of
well,
let's
say
the
first
time
you
decide
to
enable
scanning
for
a
particular
project
or
you've
got
a
brand
new
project.
You've
just
checked
in
you've
got
a
whole
bunch
of
code.
One
person
runs
the
scan
against
their
branch
and
there
are,
let's
say,
there's
a
thousand
findings.
C
The
same
thousand
findings
in
the
case
of
I
guess,
if
you're
just
Auto
promoting
all
those
wouldn't
they
would
just
be
linked
over
to
that
first
case,
because
that
first
check
and
if
they
were
all
auto,
promoted
to
vulnerabilities,
they
would
have
something
to
point
at
and
a
reference
and
then
once
somebody
and
either
branch
were
to
dismiss
those
as
false
positives,
you're,
not
gonna
kind
of
keep
seeing
the
same
findings.
Maybe
that's
the
wrong
way
to
think
about
it.
That's.
E
So
if
it's
not
in
our
DB,
the
M
R
is
not
dissing.
So
if
there's
two
branches
pulled
from
source
at
different
times,
but
those
findings
aren't
making
into
the
database
for
the
mr2
diff
against
both
branches
are
gonna,
see
a
thousand
new
vulnerabilities
plus
whatever
is
in
existing
or
thousand
existing
plus,
whatever
new
right.
That's
our
that's!
Our
problem.
A
I'm
going
to
put
on
my
liberal
arts
hat
and
think
philosophically
for
a
moment
and
hopefully
won't
cause
steam
to
cause
out
of
everybody
else's
to
spew
out
of
everybody
else's
ears.
With
this,
when
does
when
is
code
actually
vulnerable?
So
this
was
a
large
subject
area
of
discussion
in
New
Orleans
when
we
were
talking
through
this
and
the
the
where
this,
the
premise
that
is
underneath
this
particular
issue
is
that
a
vulnerability,
a
code
is
not
vulnerable
until
it's
actually
shipped,
which
is
where
we
were
looking
at
default
branch
or
a
master
branch.
A
So
what
this
approach
does
not
provide
for
us
is
any
kind
of
metrics
around
vulnerabilities
that
were
avoided
courtesy
of
having
this
particular
courtesy
of
having
this
feature,
so
you
have
visibility
into
it.
It's
not
merged.
Yet
we
have
resolved
this
before
was
actually
shipped.
So,
in
other
words,
you
could
have
been
vulnerable
about
15,000
times,
but
we
stopped
you.
We
stopped
that
from
actually
happening.
So
that's
that's
a
value
proposition
thing
that
I
would
assert,
but
that
still
doesn't
promote
it
to
a
vulnerability
itself.
A
E
Makes
sense
where
it's
challenging
is
that
makes
sense,
is
a
very
traditional
security
product
model.
We
are
now
in
a
devstack
ops
model
where
there's
monitoring
and
data
and
analytics
on
the
pre
deployment
vulnerabilities
that
either
like
they
call
it
escape,
so
they
get
into
production
or
even
like
a
Mars
delayed,
so
on,
etc.
So,
there's
there's
a
data
built
in
behind
pre
deployment,
vulnerabilities.
B
E
Thinking
out
loud
well,
it's
our
job
to
create
and
organize
an
experience
that
makes
sense.
So,
if
we're
doing
all
branches,
all
vulnerabilities
we're
not
gonna
just
dump
to
the
user
in
the
list
that
has
33,000
vulnerabilities
for
every
branch,
we
would
want
to
have
some
like
smart,
some
smarts
applied
to
that
list
and
have
like
you
know,
dropdowns,
that
you
know
default
to
default
branch
right
or
whatever
branch
they
decide
should
be
defaulted
to.
A
The
interest
of
time
and
seeing
that
we've
got
a
couple
of
questions
to
get
to
Matt
and
Andy,
would
you
so
y'all
are
enumerated
potential
use
cases
where
you'd
want
this?
Could
you
enumerate
those
on
an
issue
you
post
MVC
that
we
can
start
discussing
the
pros,
don't
mean
the
pros
and
cons
of
this
and
figure
out.
If
there's
a
direction,
we
want
to
go
on,
go
into
anything.
A
D
So
I'm
working
on
the
creating
issues
associated
well
mobilities,
doing
the
validation
on
that.
So
so
Victor
started
both
the
creation
of
those
links
and
the
deletion
of
those
links.
I
I
got
them
through
review
and
I'm,
trying
to
test
it
out
on
staging
and
having
some
problems
which
led
to
these.
It
was
working
just
fine
in
in
production.
D
D
B
Is
something
we
talked
about
before
kind
of
so
the
end
goal
is
to
have
it
just
like
related
issues
on
other
issues
or
merge
requests,
but
there
might
be
an
MVC
here
where
we
just
mirror
the
same
functionality
that
we
have
on
the
current
dashboards.
There
is
slightly
different
that
you
can
only
create
a
new
issue
and
then
relay
it
that
one
issue
and
then
that's
it.
You
don't,
if
that's
easier
to
do,
then
that's
something
we
can
go
down
for
MVC,
but
the
end
goal
is
to
have
it
just
like
Emma's
and
and
issues.
D
Okay
and
then
kind
of
my
second
question
there
is,
is
there
like
say,
have
a
an
MRI
feature,
branch
and
I
go
ahead
and
create
an
issue
for
this.
This
vulnerability,
then
it
gets
merged
into
the
branch
then
would
I
also
have
the
opportunity
to
create
another
issue
that
would
be
related
to
the
vulnerability
and
there
would
be
a
separate
issue
related
to
the
finding
or
how
does
that
kind
of
look.
D
B
D
I,
just
yeah
yeah
yeah
cases.
No,
absolutely
that's
a
that's
a
good
good
question.
I
feel
like
some
of
this
is
if
they
were
all
promoted.
Oh
I
feel
like
some
of
this
might
be.
You
need
to
play
around
with
it
a
bit
more
to
see
if
it's
a
problem
but
I
mean
yeah
ya,
know
if
anybody
has
any
answer
to
that
question.
D
Mean
I
think
the
the
easiest
thing
is
to
just
use
the
same
workflow
of
creating
an
issue
associated
with
the
finding,
whether
it's,
whether
it's
the
finding
doing
it
or
the
vulnerability
doing
it,
because
we
have
that
one-to-one
relationship
between
the
vulnerability
and
the
finding
and
we
could
like
if
we
want.
We
could
even
do
some
about
the
creation
of
that
link
from
the
vulnerability
pages
themselves
and
like
if
it's
create
an
issue
like
we
could
create
that
link
when
they
create
issues
happen
laughing.
D
B
Yeah,
so
we
have
two
versions
of
this
meeting
on
two
different
calendars.
We
should
I'll
skip
ahead
slightly
so
next
week.
We
need
to
move
this
call
which
requires
moving
it
on
two
different
calendars
and
that
gets
pretty
confusing.
I
understand
why
it's
on
both
for
visibility,
but
could
we
maybe
just
have
it
on
one
with
that?
Would
that
work
should
we
go
Highlander
on
this.
A
A
B
A
Right,
okay,
for
those
that
are
on
the
secure
stage
by
calendar,
it's
about
to
get
noisy
because
it
looks
like
you
can
invite
another
calendar
to
a
meeting
I'm
going
to
try
it
out,
and
so
this
might
create
some
noise.
Apologies
for
that
all
right!
We're
at
time!
I
now
will
dangerously
ask
if
there
are
any
additional
questions
that
should
be
covered
too
quickly
before
we
all
wrap
up
and
move
on
to
to
continue
progress
forward
on
things.