►
From YouTube: Protect:Container Security group discussion 2021-10-12
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
group
meeting
for
the
container
security
group
at
gitlab
alexander,
I
think
you've
got
our
first
item
demo
per
usual.
B
Yeah
the
work
for
the
operational
vulnerabilities
has
started
and
is
quite
underway.
We
have,
if
you
go
to
staging
and
I
think
it's
all
of
staging
and
go
to
any
vulnerability
report
in
the
project
group
and
instance
level.
You
will
see
our
new
operational
vulnerabilities
tab.
A
Thank
you,
awesome,
yeah,
great
work
on
that.
I'm
really
looking
forward
to
seeing
that
take
place.
It's
nice
to
see
that
in
staging
today's
agenda
is
pretty
short.
I
did
want
to
formally
put
this
item
through
planning
breakdown,
display,
container
scanning
packages
and
gitlab's
dependency
list.
We've
got,
will
meek
hiron
who's
from
the
secure
side
and
helps
with
their
end-to-end
tests.
A
The
idea
here
is
just
to
basically
take
what
we've
got
in
container
scanning
and
add
all
of
the
container
scanning
packages
that
are
on
the
image
into
the
dependency
list.
So
right
now
it
only
includes
application
dependencies.
It
doesn't
have
any
system
dependencies
in
that
list
and
to
provide
a
full
s-bomb
or
complete
list
of
all
of
the
dependencies
that
are
used
by
an
application.
Obviously,
you
would
want
to
have
those
system
dependencies
included
in
that
list
as
well,
so
we're
actually
not
changing
any
columns
here.
A
Almost
there
may
be
some
very,
very
small
front,
end
work,
but
it's
going
to
be
minimal
if
there's
anything
at
all
for
the
most
part
we're
just
populating
it
with
information
about
all
of
the
packages
that
come
from
the
operating
system,
so
just
to
share
my
screen
for
real,
quick
walk
through.
Let's
see
if
this
works,
hopefully
you're
able
to
see
the
right
screen
there.
A
So
the
only
difference
you
can
see
here
in
this
screenshot
there
are
a
whole
bunch
of
the
existing
application
dependencies
in
this
list.
We're
not
able
to
pull
license
information
right
now,
so
that'll
just
be
a
blank
dash.
A
The
component
will
obviously
be
the
package
with
the
version
just
matching
the
same
format.
That's
already
here
for
packager
we're
actually
going
to
list
the
operating
system
and
its
version
with
the
package
manager
in
parentheses,
and
I
think
actually
right
now
we're
just
assuming
this
based
off
of
the
operating
system,
but
that's
probably
okay
for
an
mvc.
A
It's
going
to
be
right,
nearly
all
of
the
time
unless
they've
gone
to
you
know
some
pretty
extensive
lengths
to
change
their
package
manager
and
then,
lastly,
for
the
location,
we're
going
to
fill
this
column
with
the
image
name
itself,
with
a
path
to
that
image.
Name
and
usually
those
are
really
long,
so
they'll
just
be
truncated
here
with
ellipses
and
alexander.
That
might
be
the
one
small
piece
involving
front
end
work.
A
I
don't
know
you
know
linking
to
this
and
truncating
it
I'm
guessing
that
there
might
be
a
little
bit
of
front-end
work
required.
I
again
I
don't
know-
maybe
it
just
already
works
that
way
today
by
default,
but
that
would
be
the
one
front
end
piece:
if
anything
to
do
here.
A
All
right,
if
not,
I
will
move
this
on
to
refinement.
I
think
tiago's
already
done
a
proof
of
concept
that
has
this
like
90
done,
so
my
remaining
work
is
just
to
get
those
columns
with
the
right
information
in
there
and
formatted
the
right
way,
but
we
are
really
close
to
actually
shipping
this
thing,
I
think
so
we'll
move
it
to
refinement
and
we'll
move
it
on
through
the
process.
C
Yeah
chico
pretty
much
did
all
the
background
stuff
already.
There
are
a
couple
things
I
think
we
still
need
to
do.
We
should
create
a
new
cicd
job
in
the
dependency
scanning
template
probably,
and
we
should
refactor
the
plc
said
it's
you
know
more
maintainable.
We
will
probably
just
leave
it
in
the
container
scanning
project,
but
I
think
it
needs
to
go
in
its
own
container
image.
A
C
A
C
A
It
would
be
nice
to
reuse
if
possible.
I
know,
like
some
of
the
other
groups
have
had
a
lot
of
different
images
that
they've
spun
up
and
then
it
becomes
a
lot
to
maintain.
It
also
is
costly
not
only
to
get
lab,
but
also
to
our
customers
like
every
time
we
have
a
new
job.
It
takes
like
a
full
minute
just
to
pull
the
image
and
spin
it
up
and
start
it
up
before.
You
start
executing
the
code.
A
A
All
right,
I
did
want
to
chat
just
briefly
and
then
just
barely
tackle
this
on
with
the
agenda,
so
I
apologize
for
not
putting
that
on
sooner,
but
I
just
occurred
to
me.
I
should
probably
call
out
like
this
is
step
one
in
a
number
of
steps
that
are
coming.
We
don't
have
epics
defined
for
all
of
these
steps,
yet
just
because
it's
not
really
clear
what
our
iteration
path
is
to
get
to
where
we
want
to
go.
A
But
I
thought
it
worth
mentioning
just
to
discuss
our
end
goal
for
container
scanning
here
for
a
minute
where
we're
headed
with
this
moving
these
packages
into
adding
them
to
the
dependency
list
is
really
just
one
piece
in
a
larger
set
of
steps
by
storing
the
packages
in
get
lab.
That's
one
part
in
allowing
us
to
run
container
scanning
outside
of
a
pipeline,
and
I'm
assuming
thiago
has
probably
talked
about
this
idea
with
most
of
everyone,
but
I
think
it
might
be
worth
just
bringing
everybody
onto
the
same
page
here.
A
A
You
know
to
my
earlier
point:
running
trivia
itself
takes
a
number
of
seconds,
whereas
actually
running
the
container
scanning
job
takes
around
a
minute.
Just
because
you
have
to
pull
the
image,
you
have
to
start
up
the
image
and
then
you
can
actually
start
the
trivia
scan.
So
it
takes
a
long
time
before
you're
able
to
start
scanning.
A
A
A
So
with
that
in
mind,
I
did
want
to
actually
just
verify
with
the
way
we're
doing
it
and
with
thiago's
template.
Are
we
able
to
store
like?
Are
we
storing
this
associated
with
the
image
itself
that
it
came
from
a
hash
of
the
image
or
a
pointer
to
the
image,
or
are
we
some
way
in
some
way
associating
these
packages
these
dependencies
with
a
particular
image.
C
Right
so
right
now
it
doesn't
really
work
that
way.
So
so
I
I
understand
what
you're
saying
like
you
want
to
be
able
to
detect
changes
in
the
image
and
like
only
run
a
scan
if
the
image
has
changed
right.
C
So
right
now
we
just
run
the
scan
every
time
and
then
alan
probably
knows
this
better
than
me,
but
I
believe
we
use
the
location
fingerprint
to
determine
if
it's
the
same
vulnerability
or
not,
and
I
think
the
location
fingerprint
has
the
operating
system,
the
image
name
without
the
tag
right-
and
I
think
there's
one
more
part
that
I
don't.
D
Remember,
there's
a
package
name
as
well:
the
package
version,
if
you're
talking
about
like
single
vulnerability
but
yeah
we're
not
sending
any
like
checksum
for
the
image
we
are
just
sorting
like
the
name
of
it
and
without
the
tag,
as
you
said
so
so
we
just
need
to
improve
that.
We
need
to
have
more
information,
so
we
can
easily
like
pinpoint
that
otherwise,
as
for
now,
we
cannot
do
that.
A
Okay,
that's
a
good
clarification.
I
was
hoping
we
would
get
this
and
that's
part
of
why
all
those
epics
haven't
been
created
yet
because,
like
I
said,
I'm
not
quite
sure
what
all
the
iteration
path
is,
but
if
that's
not
included
in
part
of
this
I'll,
probably
create
a
new
epic,
then
to
start
tracking
that
some
sort
of
unique
identifier
so
that
we
can
say
you
know,
okay,
here
this
image,
with
this
hash
maps
to
these
dependencies.
C
Yeah
containers
have
this
check
sum.
I
think
it's
called
the
container
id
something
like
that,
but
that's
used
to
determine
whether
or
not
an
image
has
changed
by
the
registry.
C
So
if
you
push
the
same
image
to
the
registry,
tries
it
won't
overwrite
unless
the
image
has
been
changed
and
it
uses
it
uses
a
checksum
to
do
that.
So
we
could
do
the
same
thing
with
dependency
scanning.
A
Yeah
I
mean
in
the
spirit
of
reducing
time
right.
We
could.
We
could
first
check
that
checksum
and
say
if
we
already
have
dependencies
for
that,
given
checksum,
then
we
don't
need
to
update
those
dependencies
as
part
of
the
job,
because
we
already
have
the
up-to-date
information.
If
it's
different,
then
we
know
we
do
need
to
go
update
them
right.
A
Okay,
I
will
create
that
as
a
separate
follow-on
epic,
then
so
that's
not
to
confuse
the
two.
C
So
alan,
do
you
know
if
we
have
a
way
to
run
like
background
jobs
without
a
csv
pipeline?
I
think
there's
workers
or
something
that
we
could
use.
D
B
D
A
All
right,
yeah,
good
considerations,
thanks
for
the
discussion
here
there
any
other
things
that
we
need
to
discuss
today.