►
From YouTube: Session prep review: container scanning related UX
Description
Prep walkthrough ahead of the upcoming Think-BIG session with Secure & Package team, the review includes:
• Container scanning configuration required at the project level https://docs.gitlab.com/ee/user/application_security/container_scanning/
• Displaying container vulnerabilities detected
• Filtering vulnerabilities from multiple images
• Suggested solution, current UX: create merge request with updates
• Suggested solution, future UX: auto-created merge request
• Suggested solution, future UX: show in merge request findings and solutions
• Secure/Package improvement issues for consideration
A
Hi,
I'm
kyle
from
the
secure
UX
team
in
this
video
is
in
preparation
for
a
think
big
session
hosted
by
the
package
team
they've
invited
us
to
join
them
in
talking
about
how
we
can
collaborate
and
bake
security
into
package
and
and
vice
versa.
So
this
is
just
a
that's
requested,
just
a
quick
prep
to
walk
through
the
container
scanning
feature.
A
This
feature:
searches,
docker
images
for
known
vulnerabilities
and
it's
supported
by
Clare
and
Clare,
which
are
two
open-source
tools
for
vulnerability,
static
containers.
The
note
that
I
want
to
make
here
is
that
once
your
container
is
set
up,
then
configuration
is
required
for
this
to
add
the
job
to
your
pipeline.
The
way
that
you
would
do
that
is
add
this
template
into
the
gitlab
yamo
file
and
the
other
necessary
variables
once
this
is
set
up
and
pipelines
are
running.
The
results
will
be
seen
then
in
two
places.
A
Right
now
we're
looking
at
a
project
level
and
by
the
way
this
is
a
test
project.
So
these
vulnerabilities
are
not
related
to
the
git
lab
project,
but
yeah.
So
here
at
the
project
level
and
the
vulnerability
list,
we
see
that
we've
filtered
it
down
by
container
scanning
results
only
and
if
we
take
a
look
at
this
vulnerability
here.
Actually,
if
we
look
at
more
info,
we
can
see
some
of
the
CVE
details
to
it.
A
We
even
see
a
suggested
solution
here
which
we'll
come
back
to
later,
but
I
will
note
that
there
are
some
cases
where
you
can
create
a
merge
request
from
this
area.
Now
this
flow
will
change
a
little
bit
as
in
the
future,
we'll
click
this
row
and
then
it'll
come
to
our
new
vulnerability
object,
page,
which
is
the
transition
to
making
vulnerabilities
first-class
objects.
The
second
place
you
would
see
vulnerabilities
is
actually
in
the
merge
request.
A
So
we
see
here
in
the
merge
request,
widget
that
it's
reporting
different
skinning
results,
one
of
which
is
containers
which
is
right
here
similar
as
we
saw
previously.
We
do
see
a
solution
available
here
in
this
case
and
additional
details
directly
in
the
merge
request
and
we'll
jump
into
future
iterations
to
this.
A
So
let's
just
take
a
quick
look
at
what
that
looks
like
if
the
user
is
opted
out
on
the
vulnerability
page,
there
will
be
an
indication
to
them
that
a
solution
is
available
and
then
they
will
land
on
the
object
page
and
they
can
resolve
with
the
merge
request,
then
creating
the
merge
request
with
the
solution
available.
If
it's
opted
in
which
it
is
by
default,
two
things
will
happen
is
on
the
vulnerability
list.
The
actual
merge
request
will
automatically
have
been
created
and
they
can
click
directly
to
that.
A
A
Okay,
we
have
another
issue
as
well
addressing
the
merge
requests
when
solutions
are
available
for
container
scanning,
and
that
would
look
like
this.
So
we're
looking
at
the
merge
request,
and
we
show
that
some
solutions
are
available
here
and
we
see
in
this
section
that
a
container
scanning
a
vulnerability
has
protected,
been
detected
in
this
merge
request
and
there's
a
solution
available
from
here.
The
user
could
create
merge,
requests
similar
to
how
we
saw
earlier
or
download
the
patch
locally
again.
A
This
is
a
future
iteration
that
the
one
that
will
be
before
this
is
the
suggested
solution.
One
okay,
now
a
couple
considerations
that
we
thought
of
that
we
could,
as
a
few
MVC's
for
for
securing
package
to
collaborate,
is
one
on
this.
One
is
about
the
following
scenario:
when
a
container
or
containers
are
set
up
the
project,
but
they're
not
configured
for
container
security
scanning.
This
is
a
situation
where
we
want
to
make
abundantly
clear
to
the
users
as
it's
sort
of
a
vulnerability
in
of
itself
if
it's
not
being
scanned.
A
So
we
want
this
to
support
our
ongoing
efforts
to
ensure
security
awareness
of
when
and
where
security
scans
are
being
performed.
So
a
couple
ideas
here
is
that
we
showed,
on
the
configuration
page,
that
a
container
setup
that
it's
not
configured
that
we
can
be
scanned.
We
show
in
the
container
registry
section
that
scanning
is
available,
but
not
yet
configured,
maybe
there's
some
other
brainstorming
around
how
we
can
better
communicate.
This
scenario
to
the
customer.
A
It
could
land
on
the
page
that
we
saw
earlier,
that's
pre-filtered
the
vulnerability
list,
pre
filtered
by
the
image
type,
and
then
a
third
thing
that
comes
to
mind
is
related
to
our
suggestion,
suggested
solutions
feature,
and
that
is
similar
to
what
we
last
saw
is
that
in
the
container
registry
section
is
bringing
attention
to.
Of
course,
the
vulnerabilities
that
have
been
detected
in
that
container,
but
also
when
suggested
solutions
exist
in
the
merge
requests
and
how
we
could
do
that.