►
From YouTube: How to recognize vulnerabilities between commits
Description
One of the challenges the Secure team is facing is being able to reliably track vulnerabilities between commits, when their location has changed. This is a short video showing why and how to address this issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/7586
A
Hi
everyone-
this
is
a
river
from
the
secure
team,
and
this
is
a
quick
video
about
the
issue.
The
issue
I'm
currently
trying
to
solve,
which
is
being
able
to
track
runner
abilities
between
comets
when
the
location
exchange-
and
this
is
particularly
important
for
sassed
Vernor
abilities
because
by
nature,
their
location
is
really
tied
to
the
source
code,
which
will
change
over
time.
A
So
here,
I
have
a
sample
project
where
I
have
ran
the
sass
analysis
and
it
found
one
vulnerability
here
that
is
reported
on
the
line
47
of
that
world
OGS
file
and
another
tab.
I
have
the
group
level
security
dashboard
where
we
are
showing
vulnerabilities
coming
from
the
database
that
we
first
from
the
reports
that
you've
seen
Audio
tab
on
the
job.
A
So
I
have
tweaked
a
bit
the
interface
here
so
that
we
can
show
the
created
at
timestamp,
the
Python
ID
and
the
occurrence
ID,
which
is
the
occurrence,
is
the
database
record
where
we
are
holding
all
the
information
for
vulnerability
and
also
the
start
line
and
end
line
for
for
debugging
purpose.
So,
if
you're
wondering
why
we
are
not
showing
the
Creator
that
type
stone
right
now
on
the
on
the
dashboard,
this
is
because
of
this
very
issue.
A
It's
because
it's
currently
not
really
able
so
to
show
you
how
I
would
just
open
a
new
tab
with
the
web
IDE
and
what
I
do
is
tweaking
the
five
just
updating
the
five
where
this
vulnerability
has
been
reported.
So
here
it
is
so
on
line
47
and
what
I'm
doing
is
just
adding
a
comment
there
and
what
this
does
is
pushing
down
every
lines
below
rising
incrementing
the
line
number
by
one.
A
So
SAS
analysis
is
raining,
and
this
is
we
produce
a
new
report
and
what
happened
there
is
that
when
the
report
will
be
down,
we
will
load
it
and
we
will
parse
it
and
we
will
try
to
find
a
match
with
the
existing
record
in
the
database,
and
this
matching
is
based
on
fingerprints.
One
of
them
is
a
location
fingerprints
which
is
made
of
five
paths,
the
start
line
and
the
end
line.
A
So,
as
you
can
imagine,
if
the
latter
start
line
and
the
end
line
of
champs,
the
fingerprint
will
be
different
and
then
we
won't
be
able
to
match.
So
what
would
happen
is
that
the
existing
record
will
be
considered
as
a
fixed
vulnerability
and
a
new
record
will
be
created
with
this
new
location,
and
this
is
obviously
what
we
don't
want.
A
So
here
we
can
see
that
this
is
the
same
vulnerability,
but
this
time
reported
on
line
48,
so
I
will
open
a
new
tab
of
the
dashboard
with
where
we
can
see
that
it
no
report
the
Venerable
online
48.
But
if
you
look
at
the
occurrence
ID
it's
now
ending
by
59,
whereas
before
it
was
58.
And
if
you
look
at
the
timestamp,
it's
also
different.
A
So,
as
I
said,
this
is
because
we
were
not
able
to
match
the
two
vulnerabilities.
So
we
closed
the
first
one
and
created
a
new
one,
but
this
is
obviously
the
same
one,
and
we
don't
want
to
do
that
because
we
don't
provide
a
real
old
timestamp,
and
this
is
this
is
preventing
us
from
doing
really
interesting
features.
A
So
now
what
I
did
what
I'm
doing
is
that
I
will
just
enable
the
feature
flag
for
the
new
approach
that
I'm
currently
trying,
which
is
to
leverage
the
give
to
improve
our
tracking,
so
I'm,
just
reloading,
so
that
arrays
up
take
into
account
that
that
new,
algorithm
and
I
would
just
update
again.
That's
why
by
adding
another
one
and
commenting
again.
A
So
no,
what
we
will
do
is
that,
instead
of
just
taking
the
new
reports
and
comparing
the
fingerprint
with
all
one
we
have
in
database,
we
will
take
the
existing
vulnerability
database
check
that
file
path.
And
if
they
are
part
of
the
kid
dish,
then
we
will
use
some
mappers
to
convert
the
location
from
there,
the
old
source
code,
to
the
new
version
of
the
source
code.
A
So
this
will
allow
us
to
recognize
the
fact
that
a
vulnerability
that
was
previously
on
line
47
is
now
online
48
which
allow
us
to
generate
the
same
fingerprints
as
what's
reported
on
the
new
report
and
improve
the
matching.
So
here
the
analyzes
is
down
again.
This
is
the
same
vulnerability,
but
on
line
49
and
I
would
just
open
another
tab
again
for
the
dashboard
and
we
check
how
it
goes.