►
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
our
group
meeting
for
the
container
security
group.
Thiago
is
out
today,
but
he
has
the
first
item,
which
is
to
put
the
improved
container
scanning
matching
issue
through
planning
breakdown.
A
I
agree,
I
think,
we're
getting
to
a
good
point
there
on
the
requirements
and
at
this
point
we're
just
trying
to
answer
the
question:
are
the
requirements
adequately
defined
that
we
can
move
this
on
to
start
identifying
implementation
issues
and
weights
and
move
it
onto
the
refinement
phase,
or
are
there
still
outstanding
questions
about
the
requirements
in
this
one.
B
A
The
container
scanning
engine
has
is
difficult
to
use
for
certain
customers
because
of
the
way
that
it
matches
vulnerabilities
when
you
do
a
scan
it
or
when
you
create
a
merge
request
against
the
master
branch,
what
it
will
do,
or
the
default
branch
will
do
is
take
all
of
those
vulnerabilities,
compare
them
to
the
vulnerabilities
that
have
already
been
resolved
in
the
default
branch,
and
it
won't
show
those
in
the
mr,
because
it's
trying
to
only
show
vulnerabilities
that
are
new.
A
A
So,
without
digging
into
all
the
details
of
the
matching
details
of
all
of
that,
that's
the
problem.
We're
trying
to
solve
for
is
not
everyone
merges
everything
into
the
default
branch,
some
use,
release,
branches
or
feature
branch
strategies
and
those
cause
problems
with
the
way
we're
doing
matching.
Today,.
A
Adam,
I
know
you
and
I
had
a
pretty
long
thread
in
here
about
exactly
how
we
would
want
this
to
work
and
what
problem
we're
trying
to
solve.
I
just
want
to
make
sure
do
you
have
any
other
questions
about
the
desired
behavior,
or
is
it
worth
talking
this
one
through
a
little
more.
C
Yeah,
there's
there's
a
lot
of
edge
cases
once
you
start
messing
around
with
this,
the
fingerprint
you
know
the
matching
us
mechanism
and
each
yeah,
I'm
just
not
really
sure
the
best
way
to
solve
this.
A
Yeah,
that
makes
sense,
I
mean
we
talked
about
a
few
different
potential
solutions
and
the
thread
at
the
end
of
the
day.
I
you
know
the
solution
is
secondary
to
the
problem
to
be
solved,
so
I
don't
know
if
the
next
step
for
this
one
is
a
bit
of
a
research
spike
or
you
know,
to
have
you
or
another
engineer,
go,
and
you
know
propose
a
way
to
spend
some
time
to
think
about
it
and
work
through
some
scenarios
and
propose
a
way
to
solve
the
problem.
C
I
think
a
research
spike
would
probably
be
good
because
it's
it's
just
too
difficult
to
refine
this,
as
it
is
without
understanding,
because
it's
easy
to
come
up
with
solutions
that
just
don't
don't
that
won't
work.
So
I
think
yeah.
You
need
to
spend
more
time
really
digging
in
and
having
a
a
few
different
ideas
of
approaches
and
what
are
the
drawbacks
on
some
of
them.
A
Yeah
that
makes
sense
as
far
as
the
requirements
go
or
the
intended
outcome
of
this.
Are
you
clear
on
that,
or
do
you
have
questions
still
about
the
the
problem
we're
trying
to
solve.
C
For
no,
I
think
it
I
was
confused
at
first,
but
one
of
your
comments
explained
explain
what
the
desired
behavior
was,
which
makes
sense.
C
So
yeah,
I
think
I
understand
what
the
purpose
is
so.
A
We
don't
really
have
a
research
spike,
workflow
state,
so
I
think
we'll
probably
just
leave
this
in
planning
breakdown,
but
I'll
add
a
comment
and
a
note
for
thiago
that
we'll
want
to
do
a
research
spike
around
this
before
we
start
creating
the
implementation
issues.
A
Yep
yeah:
we
could
promote
this
to
an
epic
that
might
be
a
good
solution
too,
all
right.
So
our
next
item,
I
know
john-
had
some
questions
about
our
epic
for
vulnerability
scans
against
running
containers.
I
think
he's
not
the
only
one.
I've
seen
a
few
questions
over
the
last
few
days
from
the
team,
so
it'd
be
good
to
just
go
over
this
again
one
of
the
big
things
we
want
to
do
with
container
scanning.
A
One
of
the
reasons
we
moved
it
over
to
protect
was
to
start
scanning
containers
in
production,
and
we've
had
some
really
a
high
degree
of
interest
from
customers
around
this.
In
fact,
just
for
some
historical
context
back
when
we
were
defend
and
we
were
wholly
focused
on
protecting
things
in
production,
I
would
bring
up
psyllium.
A
It's
not
common
to
have
the
secops
team
as
a
user
for
gitlab,
yet,
and
so
actually,
implementing
firewall
rules
is
something
that's
fairly
new,
but
identifying
and
fixing
vulnerabilities.
A
That's
an
area
where
there's
overlap
between
our
existing
customer
base
and
our
future
customer
base.
I
pull
this
up
too
just
because
I
think.
A
A
Again
security
operations.
They
manage
the
things
in
production,
so
they're
managing
you
know
they
would
be
very
interested
in
psyllium
and
falco
and
app
armor.
The
problem
is
that
we
don't
have
many
of
these
users
today.
So
when
we
go
out
to
talk
to
customers-
and
you
know
the
people
using
our
product-
it's
usually
not
this
team,
so
we're
trying
to
work
our
way
over
there
and
we
have
a
pretty
strong
presence
with
the
application
security
teams.
A
Today,
they're
responsible
for
the
actual
code,
there's
a
big
overlap
here
when
it
comes
to
scanning
containers
and
production.
So
again,
as
we
build
that
out,
that's
going
to
address
the
needs
of
the
appsec
team,
but
it's
also
going
to
start
to
get
the
interest
of
the
secops
team
to
drive
usage
of
other
areas
of
protect.
So
it
really
is
that
bridge
that
we're
working
to
build
between
these
two
teams-
again
all
of
that
is
just
some
context
around
this
particular
issue.
A
As
far
as
the
problems
to
solve
here,
you
know
why
is
it
that
customers
are
so
interested
in
scanning
containers
in
production?
There's
really
two
two
reasons
for
that,
and
one
is
certainly
a
far
bigger
use
case
than
the
other,
but
they're
both
valid
use
cases.
A
The
first
use
case
is,
I
hear
customers
saying
I
have
something
that
I've
deployed
five
years
ago.
It
may
have
even
been
before
get
lab
was
a
thing
at
their
company
and
it's
just
stale
code,
but
it
still
is
a
valid
production
application
and
we
have
absolutely
no
idea
what
vulnerabilities
are
in
that
code.
We
don't
know
what
packages
are
being
used
like
nobody
has
touched
that
thing
for
five
years
and
it's
embarrassing,
but
it's
there
and
we
need
to
find
out.
What's
what
vulnerabilities
exist
in
that
environment?
A
A
So,
just
having
that
comfort
to
know
that
they've
scanned,
the
actual
contents
of
what's
running
in
production
is
what
those
customers
are
interested
in.
The
second
use
case
is
there
is
a
risk
that
an
attacker
manages
to
get
control
of
a
container.
It
could
be
that
they
exploit
a
vulnerability
in
the
code.
That's
running
there.
A
Just
in
case,
an
attacker
puts
a
different
package
in
or
installs
a
package
with
a
known
vulnerability.
That
would
be
something
that
we
can
catch
again.
That
second
use
case
is
false,
far
smaller,
like
if
you're
wanting
to
protect
against
an
attacker,
your
front
line
of
defense
is
probably
going
to
be
psyllium
and
falco,
but
we
do
believe
in
defense
and
depth
and
so
having
you
know,
a
container
scan
against.
That
is
just
one
more
one,
more
layer
of
security
to
put
on
top
of
all
of
that.
A
So
as
far
as
implementation,
how
do
we
actually
go
about
this?
You
know
again.
We
have
a
lot
of
flexibility
in
that.
If
we
do
want
to
require
an
agent
or
if
we
have
to
require
cluster
admin
access,
that's
not
ideal,
but
the
feedback
we've
had
from
customers
is
it's
more
important
to
have
the
security
scan
than
it
is
to
not
give
us
that
access
at
least
that's
true
of
probably
80
of
the
customers.
A
You
know
contents
of
that
container,
whether
that's
a
live
scan
in
the
agent
or
whether
we're
snapshotting
it
with
something
like
docker
commit
again,
there's
flexibility
there,
but
it's
not
enough
to
just
scan
the
image
that
spawned
the
container.
We
actually
want
to
scan.
You
know
what's
in
the
container
itself,
so
I
I
know
that
was
a
pretty
long
explanation
there
on
this
topic.
Let
me
pause.
Are
there
any
questions
or
comments
that
I
didn't
address.
C
Is
it
sufficient
to
scan
like
in
the
minds
of
you
know,
customers?
Is
it
equivalent
to
scan
a
snapshot
of
an
image?
Is
that
equivalent
to
scanning
the
actual
running
image?
Yes,
okay,
so
they
don't
make
any
no
one's.
You
know
made
any
distinction
there.
A
No,
no
one's
worried
about
that,
because
you're
taking
the
latest
from
that
container.
So
if
that
container
was
modified
from
the
original
image
that
it
was
spawned
from
you're
still
capturing
that
differential,
so
whether
we
scan
the
container
itself
or
we
scan
a
container
image,
that's
fine!
As
long
as
it's
the
current
container,
not
the
image
that
was
sitting
in
the
registry
back
when
the
container
respond.
C
A
C
A
C
C
A
Yeah,
so
this
is
like
a
fairly
common
thing,
at
least
from
the
customers.
I've
talked
with
and
they're
almost
always
a
bit
embarrassed
when
they
tell
it
to
me,
but
basically
it
sounds
like
there's
a
project
going,
a
team
stood
up
this
thing,
they
deployed
it
to
production,
and
then
you
know
the
project
got
de-prioritized
defunded
those
developers
left
and
so
now,
there's
sort
of
just
this
thing
out
there
that
no
one's
touched
in
forever
and
you
know
it's
running
in
production,
and
so
it's
a
potential.
C
A
Should
have
access?
You
know,
I
don't
think
they've
like
lost
all
access
into
the
cluster,
it's
more
just
that
the
developer
team
has
you
know
it's
working
and
it's
not
broken.
If
it
ain't
broke,
don't
fix
it
kind
of
thing,
and
so
it's
just
been
left
there.
You
know,
so
they
still
have
credentials
to
the
cluster
they're,
just
not
doing
anything
with
it.
C
Yeah,
okay,
yeah,
because
I'm
just
trying
to
understand
like
you
know,
is
it
something
that,
because
part
of
whatever
our
solution
would
be
would
be,
you
know
something
that
would
require
having
access
to
restart
the
the
containers.
You
know
having
access
to
redeploying
having
access
to
all
that
kind
of
stuff
versus
something.
That's
just
there
can't
be
touched
and
we
need
to,
like
you
know,
get
in
somehow
into
this
container.
C
Right:
okay,
because
yeah,
I
guess
each
it
sounds
like
each.
You
know
each
setup
is
going
to
be
quite
different
than
the
other
and
we
might
come
up
with
some
solutions
that
will
work
for
some
of
them,
but
not
others.
C
Now
I
mean
there
are
certain
workflows.
I
guess
that
maybe
might
be
a
bit
more
universal
in
terms
of
install
this
service
into
your
into
your
your
app
your
your
container,
and
then
you
can
run
a
scan,
but
if
there's
things
that
rely
heavily
on
the
ci
cd
workflow,
that
would
be
a
pain
point.
A
C
A
Right,
yeah
and
they're
not
going
to
want
to
do
that.
No,
no!
If
it's
been
abandoned,
you
know
no
one
wants
to
touch
this
thing
more
than
they
have
to
you
know
they
wanted
to
go
in
and
do
a
scan,
find
the
vulnerabilities
and
then
go
take
that
to
the
development
team
and
say
you
know
this.
This
abandonware
that
you've
you've
built
it's
time
to
unabandon
it
and
at
least
fix
these
vulnerabilities.
C
Okay,
because
yeah,
like
I
said
the
the
you
know,
an
easy
solution
is
like
where
we
don't
have
to
reconfigure
their
whole
workflow.
It's
just.
We
provide
them
with
some
instructions
that
say
download
this
particular
application
and
then
run
it,
and
then
it
can
maybe
configure
itself
to
run
every
day
in
their
pod
in
their
container.
And
then
it
can.
A
Yep
absolutely-
and
so
you
know-
and
we
may
want
to
build
all
of
that
out
too,
but
keep
in
mind
that
we
try
to
be
iterative
right.
So
if
we
can
get
a
solution
out
the
door
and
then
provide
a
second
workflow,
you
know
that
maybe
for
those
users
who
are
pretty
heavily
using
gitlab
in
the
future,
you
know
we
can
always
carve
this
up
and
iterate
our
way
through
it
too.
A
A
Yeah,
so
hopefully
that
helps,
I
know
not
everyone
who
has
questions
on
this
is
on
the
call
today.
So
just
you
know,
if
you
have
additional
questions
or
if
we
want
to
discuss
it
again
in
the
group
conversation
next
week,
please
feel
free
to
bring
it
back
up
and
we
can
talk
through
it
again.