►
Description
Container Scanning Multi-Image Code Walkthrough project
https://gitlab.com/adamcohen/container-scanning-multi-image-code-walkthrough
Google doc with additional details
https://docs.google.com/document/d/1wKiKCWRRw4h2dt4rZbfYSRQj1YCztftz5KW7bFIB4kY
Note: 7:08 - the vulnerability occurrences are _not loaded from the database_ in the pipeline view - they're loaded from the container scanning report artifact file. Vulnerabilities are only loaded from the database in the "Security & Compliance - Vulnerability Report" screen which applies to the project as a whole.
A
This
video
will
focus
on
container
scanning,
but
the
process
should
be
the
same
for
other
scanning
tools,
we'll
start
by
importing
a
project
which
uses
the
container
scanning
tool
to
scan
two
of
the
same
docker
images
as
separate
jobs
in
the
pipeline,
we'll
click
the
import
project
button
and
then
click
on
the
repo
by
URL
button.
Now
we'll
paste
the
URL
to
the
repository
of
the
walkthrough
project,
which
will
be
available
in
the
description
of
the
video,
we'll
then
set
the
visibility
level
of
the
project
to
public
and
we'll
click
on
the
create
project
button.
A
If
we
look
at
the
imported
project,
we
can
see
that
there
are
two
directories:
Alpine
1
and
Alpine
2
inside
each
of
these
directories
is
a
docker
file
with
the
same
contents,
which
uses
the
Alpine
3.7
operating
system
as
the
base
image.
This
base
image
was
chosen
specifically
because
it
has
a
single
known
vulnerability
which
will
allow
us
to
demonstrate
how
the
rails
code
processes
and
displays
the
resulting
scanner
report.
A
If
we
look
at
the
gitlab
CI
demo
file,
we
can
see
that
there
are
two
build
jobs
which
are
the
same,
except
for
the
name
of
the
docker
image
being
used.
The
first
job
builds
the
Alpine
one
image
and
the
second
job
builds
the
Alpine
2
image,
both
of
which
are
using
the
docker
files
with
the
Alpine
3.7
operating
system.
A
We
can
see
that
there
are
two
stages,
each
with
two
jobs.
The
first
stage
is
responsible
for
building
the
docker
images
from
the
Alpine
one
and
Alpine
two
docker
files,
and
the
second
stage
is
responsible
for
running
a
container
scan
against
the
two
built
images.
If
we
view
the
output
for
the
first
build
job,
we
can
see
that
it
builds
the
Alpine
one
image
and
the
output
for
the
second
build
job
shows
that
it
builds
the
Alpine
two
image.
A
If
we
view
the
output
of
the
first
container
scanning
job,
we
can
see
that
it
scans
the
outline
one
image
and
finds
a
single
vulnerability
for
the
M
USL
package.
If
we
look
at
the
output
for
the
second
container
scanning
job,
we
can
see
that
scans
the
outline
to
image
and
finds
the
same
vulnerability
in
the
M
USL
package.
A
Now,
let's
look
at
the
screen
in
further
detail,
so
what
happens
exactly
when
this
page
is
loaded?
In
order
to
explain
what
happens?
We
can
refer
to
a
Google
document
which
outlines
the
code
that
executes,
while
rendering
the
security
page
will
open
the
document
alongside
the
security
page,
to
help
describe
this
process.
The
URL
to
this
document
will
be
provided
in
the
description
of
the
video
when
you
first
load
up
the
security
page,
it
executes
the
security
action
from
the
pipeline
controller,
which
is
responsible
for
rendering
the
view
the
pipeline's
show
template
is
then
displayed.
A
This
template
renders
a
partial
contain
the
pipeline
jobs
and
security
tabs.
If
we
open
this
with
tabs
partial,
we
can
see
that
this
renders
another
partial
which
includes
the
contents,
the
pipeline
jobs
and
security
tabs.
The
tabs
content
partial,
is
then
responsible
for
loading
the
pipeline,
in
it
view
module
the
pipeline.
In
it
view
module
contains
the
code
for
creating
the
severity
and
report
type
drop-down
menus,
as
well
as
displaying
the
list
of
vulnerabilities.
The
report
type
drop-down
menu
is
populated
from
the
state
J
s
file,
this
state
J
s
file
loads.
A
A
A
A
A
A
If
we
paste
the
curl
command
into
the
terminal,
we
first
need
to
remove
everything,
except
for
the
URL,
once
we've
done
that
we
can
attempt
to
send
the
get
request,
although
unfortunately
it
fails
with
a
401
unauthorized
error.
The
reason
for
this
error
is
because
we
need
to
send
an
authentication
token.
We
can
consult
the
docs
to
find
out
more
information
about
the
different
authentication
mechanisms
for
our
purposes,
we'll
use
a
personal
access
token
and
we
can
copy
the
required
header
value
from
the
docs.
A
A
A
A
A
As
you
can
see,
the
name
returned
by
the
database
entry
matches
the
one
in
the
UI
and
the
raw
metadata
contains
additional
information
about
the
vulnerabilities
such
as
the
URI
to
the
docker
image,
where
the
vulnerability
originated
from,
as
well
as
the
base64
encoded
diff,
which
can
be
used
to
remediate
the
vulnerability,
you'll
notice
that
only
a
single
vulnerability
is
returned
which
matches
the
Alpine
one
image.
Next,
we'll
discuss
why
only
a
single
vulnerability
is
returned
from
the
database
and
displayed
in
the
UI,
even
though
there
were
two
images
scanned
each
with
their
own
vulnerability.
A
A
The
location
fingerprint
is
generated
by
the
security
locations
module
and
the
fingerprint
data
for
the
container
scanning
report
comes
from
the
container
scanning
class
which,
as
you
can
see
from
the
code,
is
defined
as
the
operating
system
concatenated
with
the
package
name.
The
fingerprint
method
then
creates
a
sha-1
hex
digest
of
these
values.
We
can
generate
the
same
hex,
digest
by
hand
by
using
Alpine
version
3.7
as
the
operating
system
and
mus
L
as
the
package
name.
A
We
can
see
that
this
value
matches
the
one
from
the
database,
which
starts
with
6
6
e
to
4.
This
now
gives
us
some
insight
into
why
only
a
single
vulnerability
is
being
displayed
by
the
UI.
If
we
switch
back
to
the
merge
report
service
and
look
once
again
at
the
D
duplicate
occurrences
method,
we
can
see
that,
even
though
the
two
vulnerabilities
came
from
two
different
docker
images,
because
the
location
fingerprint
only
includes
the
operating
system
and
package
name,
which
is
the
same
for
the
two
vulnerabilities,
the
code
considers
them
to
be
duplicates.
A
This
means
that
when
two
separate
reports
from
two
different
docker
images
contain
the
same
vulnerability
when
the
reports
are
merged,
a
race
condition
occurs
and
the
first
vulnerability
to
be
encountered
is
the
one
that
wins
the
race
and
ends
up
being
saved
to
the
database
and
displayed
in
the
UI.
In
our
case,
this
happened
to
be
the
vulnerability
associated
with
the
Alpine
one
image.
If
we
were
to
rerun
this
pipeline
a
few
times,
this
would
probably
change
the
Alpine
2
image
because
of
the
race
condition
which
will
produce
different
output
each
time.