►
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
All
right,
welcome
to
our
group
meeting
for
the
container
security
group
looks
like
we've
got
a
couple
new
things
to
demo
from
alexander.
I
don't
have
either
of
those
pulled
up
at
the
moment,
but
maybe
I
can
just
share
the
notes
document.
A
So
it
looks
like
alexander
has
been
working
to
add
in
the
yaml
mode
for
editing,
which
is
great,
so
you
can
now
select
which
policy
type
you
want
to
have
and
it
scan
execution
is
an
option,
and
then
you
can
enter
the
yaml
for
that
policy
there
and
then
paul's
been
working
on
the
policy
page.
It
still
is
here
in
this
tab,
but
it
looks
like
he's
added
a
policy
type
column,
so
you
can
see
it's
a
network.
All
of
these
are
network
type
policies.
A
So
for
the
next
one
I
wanted
to
put
the
container
scanning
we've
kind
of
gone
through
a
few
different
names
here:
the
production
container
scanning
or
cluster
image
scanning
work
through
planning
breakdown.
I
think
we
already
did
this
on
the
back
end,
but
we
have
not
done
the
front
end
planning
breakdown
piece
so
and
actually
some
of
this
may
end
up
impacting
the
scope
of
the
back
end
work
just
slightly,
but
I
don't
think
it's
going
to
be
any
sort
of
huge
change,
so
annabelle.
B
Yeah,
if,
if
I
don't
have
to
walk
through
it,
then
great,
if
alan
were
you
able
to
watch
the
video
okay,
then
I
don't
know
if
it's
worth
me
walking
through
it
all
again.
I
did
see
that
matt
commented
on
the
issue
about
the
tab,
naming
that
he
might
not
like
the
pipeline
operational
tabs.
He
prefers
application
operational.
B
I
need
to
go
back
to
our
last
two
participants,
who
were
clear.
We
asked
what
application
meant
to
them
and
they
said
I
believe
it
was
more
to
do
with
your
code.
So
they
were
thinking
like
application
only
means
sassed
dependency
scanning,
maybe
maybe
they're
thinking
it
doesn't.
I
don't
know
I've
got
to
go
back
and
look
at
that
and
then
ethan
finally
got
back
to
me
too,
and
he
said
that
he
preferred
operational
and
pipeline.
A
A
So
for
now,
let's
plan
on
pipeline
and
operational
and
yeah,
let's
chat
with
matt
and
I
think
that's
a
great
idea
to
go
back
and
just
revisit
those
again,
but
it's
a
two-way
door
decision
is
the
nice
thing.
So
you
know,
even
though
we
need
to
make
a
decision,
so
we
can
go
forward
and
implement
it.
It's
not
like
it's
stuck
forever.
We
can
always
go
back
and
change
it
later.
If
we
get
good
feedback
or
research.
That
shows
that
something
else
is
a
better
choice.
B
Yeah
yeah,
and
luckily
it's
not
really
it's
not
a
change
for
people
who
are
already
using
the
existing
vulnerabilities
report,
because
they'll
just
end
up
on
that
first
tab
anyway,
so
they'll
they
won't
notice
a
difference
and
a
few
other
people
or
users
didn't
even
notice
the
tabs
at
the
top.
So
hopefully
it
won't
change
much
for
them.
We
can
also
do
like
a
call
out
once
we
add
this
new
tab.
We
can
add
a
little
pop-up.
A
A
Excuse
me,
so
I
think
the
groups
can
work
almost
entirely
independently,
as
I
was
thinking
about
it
just
a
little
bit
more.
I
realized
that
this
empty
state
does
have
a
small
dependency
on
the
back
end,
so
the
first
iteration
that
ellen
you're
working
on
isn't
really
created
by
a
policy.
It's
just
part
of
the
pipeline
job,
and
so
this
mock
would
have
to
wait
until
you
actually
can
manage
these
through
a
policy.
So
that
would
be.
A
A
Anyway,
it's
that
piece
where
you
set
the
access
token,
the
service
token
for
running
the
job,
there's
going
to
have
to
be
front-end
and
back-end
coordination
for
that
last
piece.
A
B
The
that
extra
token
issue
that
I
worked
on
on
friday
victor
has
some
questions
about
that
too,
and
I,
I
honestly
don't
know
how
to
answer
them,
because
I
just
don't
know
much
about
this,
so
I
think
he
was
confused
about
having
two
tokens
and
what
happens
if
you
only
fill
out
one
of
them
or
I
don't
know
if
there's
a
better
solution
on
that
issue.
Let
me
link
it.
A
Okay,
yeah
thanks.
I
can
help
to
address
some
of
those,
maybe
ellen
you
can
as
well.
A
A
Just
wanted
to
clarify
the
problem
to
be
solved
here
is
that
sometimes
customers
have
different
branching
strategies.
We
kind
of
assume
that
they
all
follow
a
default
branching
strategy,
where
they're
all
merging
everything
into
the
default
branch
and
that's
their
release
branch,
but
not
all
customers
do
that.
Sometimes
they
actually
release
off
of
other
branches.
A
You
know
the
branch
that
they
want
to
compare
these
two
sometimes
is
not
the
default
branch.
They
actually
want
things
compared
against
a
different
branch,
a
feature
branch
we
don't
again.
There
are
a
number
of
different
ways
that
we
don't
support
this
well
in
gitlab,
but
one
of
those
is
the
way
that
we
handle
deduplication
of
findings
with
container
scanning
based
off
of
the
image
name.
A
A
A
The
problem
is
that
not
all
customers
use
this
naming
convention
with
their
container
scanning
images.
Sometimes
you
know
they
organize
things
by
changing
the
name
of
the
image
itself,
like
they'll,
insert
the
name
of
the
branch
or
the
name
of
the
release,
and
they
actually
still
want
these
things
to
be
deduplicated
and
instead
of
showing
duplicates.
So
that's
really
the
problem
to
be
solved.
A
There's
a
pretty
long
chain
of
ideas
here
in
the
comments
section
on
how
we
might
go
about
solving
that
problem.
But
you
know
without
getting
into
the
implementation
solution.
That's
really
what
we're
wanting
to
solve
is
just
introduce
more
flexibility
for
customers
who
have
different
naming
strategies,
and
actually
you
know,
there's
no
guarantee
that
all
customers
are
going
to
follow
this
exact
naming
convention.
A
They
all
may
have
slightly
different
naming
conventions.
So,
ideally,
the
solution
will
give
us
the
flexibility
to
define
you
know
which
part
of
this
string
is
static,
and
you
know
should
be
compared
to
identify
an
identical
image
for
deduplication
and
which
part
of
the
string
is
variable
and
should
be
disregarded.
A
It
looks
like
from
the
comments
in
here
this
one
is
not
quite
ready
to
move
on
to
refinement,
but
I
just
wanted
to
bring
some
attention
to
it,
since
this
is
the
next
thing
on
the
container
scanning
list
after
we
finish
our
production
container
scanning
and
so
just
wanted
to
bring
some
attention
to
it.
Since
that's
coming
up
in
the
near
future,.
A
A
That's
that
I
I
don't
know
that
that
really
makes
a
difference.
If
you
have
multiple
container
scanning
jobs,
would
that
make
a
difference
alan?
I
would
think
that
you
would
still
handle
the
deduplication
in
the
same
way
for
each
job.