►
From YouTube: Protect:Container Security group discussion 2021-07-14
Description
https://docs.google.com/document/d/1qCwZfoo1A-FihE2ifzd4ZT_Mpz-xFzZvAPJ7pJvWCEY (internal document)
A
Welcome
to
our
weekly
container
security
group
meeting
so
today,
oh,
we
actually
have
a
couple
other
agenda
items
so
we've
got
alan
has
a
demo
for
cluster
image
scanning,
which
is
great,
really
excited.
We've
got
the
first
version
of
that
out
in
alpha.
So
if
you
have
time
check
it
out,
we've
got
our
documentation
on
the
website
too.
A
So,
mostly
for
today,
I
wanted
to
just
have
a
brainstorming
open-ended
discussion,
see
if
we
can
come
up
with
any
good
ideas
for
a
good
solution
on
how
to
improve
the
container
scanning
matching,
it's
a
really
hard
problem
to
solve,
and
fundamentally
the
problem
is
that
right
now,
the
way
it
works
in
gitlab.
The
findings
are
properly
deduplicated.
A
B
B
That
was
the
main
downside.
So
then
we
discussed
locking
that
making
that,
like,
okay
once
you've
set
this,
you
can't
undo
it
after
that.
I
I
don't
think
I've
written
this
anywhere,
but
there's
been
a
magic
set
of
console,
commands
to
to
kind
of
declare
bankruptcy
and
start
again,
yeah
that
I
think
could
come
in
handy
here.
So
if
you
find
yourself
in
a
situation
where
you
know
what
I
I
need
to
change
and
reset
things,
then
maybe
that'll
be
a
an
interesting
thing
to
consider.
A
B
A
B
B
A
customer
that
doesn't
deploy
from
master
or
maybe
they
deploy
from
master
to
a
production
environment
and
they
deploy
from
stage
into
a
staging
environment
and
they've
got
a
workflow
that
tells
them
hey.
You've
got
to
do
staging
then
master.
So
then
what
happens
in
these
situations?
Is
that
not
only
want
to
track
a
real
estate
master?
You
want
to
track
them
in
staging
as
well
and
when
you're
first
merging
you
don't
want
to
compare.
So
you
say
you
create
a
feature
branch
to
implement
something.
B
B
A
C
A
You
know
the
threat
insights
group
is
more
suited
to
solve
anyway
for
everyone
whenever
that
does
come
up
on
the
roadmap,
but
really
I'm
looking
at
customers
even
suppose,
you're
still
just
following
the
default
flow
of
merging
into
your
default
branch
and
releasing
off
of
your
default
branch.
If
your
naming
strategy
for
your
images
differs
from
what
we
expect
like,
if
you
have
the
branch
name
and
the
tag,
then
it
throws
it
off
so,
like
then,.
A
Right
so
I
think
you
know
we
don't
need
to
solve
everything
with
this
iteration,
but
even
just
like
the
example
in
that
proposal,
description
says:
you
know
if
you've
got
a
master
branch
and
a
feature
branch
here-
and
you
know
the
branch
name
is
in
the
in-
is
in
the
tag.
It's
not
going
to
properly
correct.
A
Yeah
so
I
know
I've
talked
about
different
branching
strategies
and
that's
even
how
I
kicked
off.
This
discussion
was
mentioning
different
branching
strategies,
but
yeah.
We.
We
definitely
should
d
scope
this
to
just
focus
on
the
use
case
of
different
image
names.
But
still
you
know
we
don't
want
to
solve
that
broader
problem
yet,
but
that's
outside
of
the
scope
of
this
epic,
let's
just
focus
on
when
the
user
is
merging
from
a
branch
into
the
master
branch.
How
can
we
make
sure
that
things
are
always
properly
deduplicated,
regardless
of
their
image?
B
E
This
was
just
we
used
to
document
how
it
works
currently.
So
in
the
proposal
another
comment
down
there,
I
was
still
working
on
the
pmc
or
following
that
approach
using
the
cs-based
image.
As
you
know,
the
base
image
against
which
the
you
know
all
the
musicians
entire
games,
it
is
still
at
the
poc,
I
would
say,
since
a
lot
of
cases,
it
doesn't
work
and
there
are
three
performance
issues
as
well
in
terms
of
reading
the
rallying
of
the
seas,
basically
from
the
ncaa
file.
E
That
is
quite
a
bit,
not
performant
one.
So
but
overall
it
works.
Fine.
The
works
that
I
mentioned.
So
what
I
did
was
the
cs
based
image.
It
extracts
that
value
only
for
the
pipeline
that
runs
against
a
non-default
branch.
So
if
it
runs
on
a
default
branch,
it
would
not
come
back
against
the
sales
based
branch.
E
E
So
that
way,
the
fingerprint
generated
would
be
same
as
what
is
in
the
default
branch
and
will
leave
duplication.
It
would
pick
up
and
yeah
it
would
be
even
bigger.
So
that
worked
fine,
but
there
are
a
few
questions
on
that.
If
we,
if
the
customer
needs
to
update
the
default,
runs
or
the
default
image,
then
that
use
case
might
not
work
properly
as
they
expect,
because
then
the
fingerprint
will
again
change
and
the
newly
generated
vulnerabilities
would
be
duplicated
again
because
the
figure
will
change.
B
A
Yeah
I
mean
I
don't
expect
it
to
be
a
common
use
case
for
customers
to
be
changing.
That
variable
right,
like
you,
set
it
up
for
the
project
and
it
really
should
just
be
stable.
It's
going
to
be
really
a
unusual
scenario
for
them
to
change
that
and
I
think
if
we
have
requirements
like
you
know,
you
have
to
delete
all
your
vulnerabilities
or
you
know
I
think
we
can
put
some
documentation
and
some
caveats
around
that
sort
of
a
scenario,
because
it
really
is
an
edge
case
scenario.
A
B
E
So,
and
also
tiago-
and
I
had
a
about
the
same-
we
could
either
do
using
a
ci
variable
or
we
could
also
reduce
the
configuration
scheme
screens
for
the
continuous
grading
as
we
discussed,
but
it
turns
out
that
if
we
have
multiple
container
spanning
jobs
running
on
the
same
pipeline,
the
confirmation
screen
will
not
work
because
this
confirmation
stream,
we
assume
that
there
will
be
only
one
base
image
but,
let's
say
a
project
that
pushes
two
base
images
link.
I
think
one
is
mentioned
in
the
comments
as
well.
B
One
container
builds
one
app
and
another
container
use
a
different
app,
but
they
both
use
the
same
base
image.
Any
vulnerability
on
that
base.
Image
will
be
on
both
on
both
generated
images,
which
means
they're
the
same
once
you
fix
it.
You
you
fix
it
in
both
and
docker
understands
that.
If
you
look
at
the,
if
you
do
a
docker
info,
you
you
see
the
layers
in
there
and
the
and
the
manifest
not
the
manifest.
What
is
it
called?
B
B
A
A
Right
now,
container
scanning
is
a
very
noisy
scanning
job,
and
so
anything
we
can
do
to
reduce
that
noise
and
consolidate
vulnerabilities
and
reduce
the
overall
work.
If
there's
only
one
fix
for
the
security
team.
You
know
really
should
only
be
one
vulnerability
in
that
case,
and
we
should
just
notate
within
that
vulnerability
all
the
different
areas
that
are
affected
by
that
same
vulnerability,
and
so
that
way,
using
just
the
clutter
and
the
sheer
volume
of
things
that
they
have
to
go
through
in
triage.
B
Something
around
that
part
with
when
I
that
I
proposed
on
the
threatening
sites
group
was
and
and
it's
it
wasn't,
even
that
the
original
idea,
because
I
think
philippe
he
had
the
same
sort
of
idea
with
a
different
take,
but
basically
facilitate
the
triage
by
by
creating
a
reusable
list
of
reusable
triage
that
you
can
say,
hey
I've
already
looked
at
these
cves
and
in
the
context
of
an
application
that
runs
in
a
certain
way.
These
are
all.
B
So
as
you're
triaging
things-
and
you
dismiss
it,
you
say
oh
and
by
the
way
add
this
to
to
this
exception
list
here
and
then
for
each
project
could
apply
that
list
and
say
you
know
anytime,
you
scan
things,
apply
this
list
here
and
then
at
at
the
end.
You
only
get
the
stuff
that
you
want
and
I'm
mentioning
this
because
because
you,
you
made
a
helpful
comment
to
me
anyway.
The
objective
is
to
reduce
the
number
of
to
reduce
the
noise.
A
Yeah,
there
are
some
other
ways
that
we
can
get
some
good
smarts
around.
That
too.
All
of
that
is
further
out
on
our
roadmap
than
you
know
really
the
foreseeable
future,
but
if
there
is
some
sort
of
overlapping
solution
that
also
addresses
you
know
the
main
point
of
this
epic,
I'm
definitely
open
to
taking
those
on
together.
If
that
helps
make
this
easier
in
some
way,.
B
E
Instead
of
reading
it
from
the
ciaml
file.
I
was
thinking
if
we
could
modify
the
schema
of
the
report
and
from
the
container
scanning
and
gcs
project.
We
could
inject
that
into
the
system
unfold
itself
so
that
in
the
rails,
when
we
read
back
the
report
json,
we
don't
query
the
gitlab
crm
file.
Instead,
we
just
go
to
the
report
file
and
get
the
base
image.
E
E
B
A
A
B
It
will
make
it
easier
to
implement
this,
and
we
probably
wouldn't
want
to
do
it
before
anyway,
not
not
because
not
only
because
it'll
be
harder,
but
because
it's
you
know,
it'll
be
through
almost
like
throw
away
work.
Somebody's
gonna
have
to
double
up
on
that,
and
the
second
part
is
what
sashi
was
saying:
the
the
the
index
table.
So
the
idea
behind
the
index
table
is
there's
a
very
large
table.
B
That's
hard
to
search
because
there's
some
tricky
joins
the
the
index
table
or
the
lookup
lookup
table
is
relies
on
some
triggers
whenever
things
are
instead
or
updated,
it
updates
that
lookup
table.
So
then,
when
you're
generating
reports
and
doing
comparisons,
you're
reading
off
that
easy
to
query
table
and
then
to
display
things,
you
go
back
to
the
to
the
source
of
truth,
which
are
the
the
occurrences
tables.
B
A
B
Yes,
so
there's
a
huge
table
called
vulnerability
occurrences
and
in
order
to
show
reports
you
need
to
you
need
to
do
some
joints
with
all
the
tables
that
are
not
not
that
small
either.
So
then,
the
general
idea
is
instead
of
doing
those
joints
and
doing
that
that
query,
that's
currently
timing
out
actually
for
large
projects.
If
you
go
to
to
the
gitlab
group,
get
labor
group
and
go
for
a
vulnerability
report,
you
get
some
time
out.
E
E
D
A
A
B
So
the
the
first
challenge
is
that
what
what
sashi
described
in
terms
of
deduplicating
all
the
duplication
work
happens
in
this
store
report
service,
so
that
that's
the
thing
that
reads
the
json
file
passes.
The
the
security
report
then
goes
and
compares
and
duplicate
things,
so
that
service
is,
is
a
beast
and
it's
hard
to
to
work
with.
So
we
want
to
wait
for
the
refactor.
B
Which
is
tackling
the
performance
issue
that
sash
is
talking
about,
so
we
would
have
the
same
issue.
The
the
our
issue
is
a
little
bit
different.
It's
not
so
much
that
the
table
is
big,
but
that
doesn't
help
it's
because
to
do
the
lookup
that's
been
proposed
in
his
solution.
That's
a
sub
string
in
a
column.
You
can't
index
that
because
it's
basically
json
in
a
column,
so
you'd
need
to
read
every
row,
pass
the
json
and
then
search
for
what
you're
looking
for
in
the
json
and
an
easier
way
to
do.
A
A
A
B
B
A
B
I
mean
anything
helps
right,
even
if
we,
it
just
means
we'll
be
waiting
less,
but
we
we
probably
wouldn't
we
probably
wouldn't
be
able
to
make
this
feature
live.
Without
that
performance
work
you
could
you
could
throw
in
a
feature
flag
to
say,
hey
this.
This
won't
be
turned
on
until
that
performance
is
resolved,
and
then
you
can
just
wait,
but
at
some
point
you
need
to
do
it.
A
B
A
A
A
B
Like
if,
if
in
in
your
place,
I
probably
wait
and
if,
if
if
you
happen,
if
it
happens
to
like
once,
it's
all
refined
and
ready
to
go,
if
you
find
that
it's
best
to
help,
then
jump
in
and
I
can
coordinate
between
the
two
groups,
but
I
I
I
don't
see
with
without
helping
the
threatening
sides.
I
don't
see
us
doing
this
much
sooner
than
13,
6,
sorry,
14,
6.,.
A
B
A
Okay,
so
we
so
yeah
we
wouldn't
even
start.
So
I'm
glad
we
have
a
plan
here.
I
think
we'll
probably
want
to
just
document
this
really
well
and
then
put
it
on
the
shelf
and
then
likely
it
makes
sense
to
pick
this
up.
You
know,
after
that,
refactor
is
done
in
143
or
14
4
yep,
all
the
work
that
we
can
and
then
we'll
see.
You
know
where
the
work
is
at
at
that
point
for
the
the
trigger
work
you
know
maybe
we'll
pitch
in
and
help
out
some
there.
C
C
A
B
E
You
could
still
do
it,
but
I'm
still
not
sure
how
the
refactor
would
end
up,
because
we
have
this
parcel,
which
is
actually
more
logical.
That's
at
least
what
we
want.
If
the
refactor
doesn't
that's
the
parser,
I
think
it
would
be
fine
to
start
yeah.
I'd
still,
maybe
wait
for
the
reflector
or
just
to
see
what
you.
B
B
A
We
could,
I
would
say,
that's
partially
up
to
you
on
the
engineering
team.
I
don't
have
a
super
strong
opinion
there,
but
you
know
it's
not
like
we're
going
to
be
delivering
any
value
to
customers
by
picking
it
up
and
then
stopping
and
picking
it
up
again.
So
I
I
don't
know
I
guess
I
have
a
weak
preference
for
just
waiting,
just
putting
the
whole
thing
on
pause
and
picking
it
up.
Yeah.
B
A
B
Yeah,
I
was
going
to
suggest
if
you,
if
you
could
move
it
to
the
epic,
then
as
as
the
as
the
next
step,
then
after
that
we
could
look
at
the
planning
breakdown
for
it
and
write
implementation
issues.
Basically,
while
this
thing
is
in
the
hot
cache,
you
know
l1
l2,
whatever
one
is
the
the
fast
one
write
it
off
there.
So
we
don't
have
to
remember
all
this
three
months
from
now.