►
From YouTube: How project fingerprint is used in Gitlab backend
Description
In this video we will try explaining relationship between vulnerability_feedback and vulnerability_occurrence data model. This will change in near future. https://gitlab.com/gitlab-org/gitlab/-/issues/205489
A
I'll
try
to
explain
where
the
project
fingerprints
comes
from
and
have
we
used
project
fingerprint
column
in
our
system
in
get
lab
project
fingerprint
column
is
taking
place
in
one
dribble
to
feedback
table
and
it's
also
taking
place
in
vulnerability
occurrences
table
and
the
purpose
of
project
fingerprint
is
just
to
make
a
relationship
between
vulnerable
to
feedback
and
vulnerability
occurrences.
You
might
wonder
why
we
don't
have
this
relationship
in
database
as
a
foreign
key.
The
reason
we
don't
have
this
relationship
as
the
database
as
a
foreign
key.
Is
that
excuse
me?
A
We
don't
persist
all
of
the
occurrences
that
we
found
it
a
database.
That's
why
we
need
some
kind
of
logical
relationship
so
that
we
can
associate
between
the
vulnerable
to
occurrences
and
vulnerable
to
feedback.
So
we
give
you
an
example.
When
you
create
an
M
R
in
grid
lab,
you
have,
you
can
see
the
vulnerabilities
in
MRV
jet
and
these
vulnerabilities
that
is
reported
are
not
yet
saved
in
the
database.
A
It
is
dismissed
and
the
way
we
know
that
this
mouldability
is
dismissed
is
that
because
they
have
the
same
project
fingerprint,
it
is
the
same
for
the
security
dashboard.
But
there
is
only
one
difference.
Is
that
the
vulnerabilities
that
are
listed
here?
They
are
coming
from
the
database,
but
they
are
still
associated
with
vulnerability
feedback
using
project
fingerprint.
A
So
when
we
click
venerable
T
here-
and
we
want
to
create
a
little
bit
of
feedback
if
I,
just
open
that
worked
up
here
and
we'll
say,
I
want
to
dismiss
this
vulnerability.
So
we
send
some
data
to
the
backend
and
to
create
one
dribble
feedback
and
the
most
important
data
that
we
send
in
terms
of
making
Association
here
is
to
feedback.
So
here
this
entity
is
in
the
database,
but
this
is
not
yet
in
the
database.
A
A
So,
for
the
dashboard
part,
this
method
here
makes
a
join
with
feedback
vulnerable
to
feedback,
and
this
is
the
relationship
again,
the
fingerprint
we
make
a
joint
for
for
the
the
dashboard
because,
as
I
said
before,
the
the
vulnerabilities
that
are
coming
to
dashboard
our
persisted,
because
these
are
the
vulnerabilities
that
are
in
the
default
branch
for
the
M.
Our
widget
is
different.
So
we
take
the
the
vulnerability
feedback
from
the
database,
grouped
by
project
fingerprint
and
try
to
match
them
by
occurrences
project.
Fingerprint
occurrences
that
I
just
found
by
analyzers
reported
by
analyzers.