►
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.
B
I
know
the
feeling.
That's
me,
that's
me
at
6
30
in
the
morning
first
thing
in
the
morning.
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.
B
A
The
point
that
actually
could
I
agree,
I
think
that's
a
great
idea.
You
know
if
you
were
to
change
that
pattern,
match
that
regular
expression.
For
any
reason,
you
might
also
want
to
just
wipe
out
all
of
the
previous
container
scanning
findings
and
start
clean
at
that
point.
Yeah.
B
What
else
to
be
considered
so,
I
think
sashi,
you
can
keep
me
honest
here,
but
I
think
every
every
solution
that
we
thought
about
has
a
dependency
on
tracking
vulnerabilities
in
the
known
default
branch.
B
Yeah
and
and
that's
something
that's
not
supported
at
the
moment-
it'll
be
it'll,
be
a
something
for
threatening
sites
to
to
look
at
and
and
put
in.
So,
as
you
said,.
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
So
with
this,
this
approach,
I'm
not
trying
to
solve
for
all
of
those
different.
You
know
all
of
those
different
workflow
scenarios,
because
I,
I
think
that's
a
bigger
problem
than
what
we've
got
here
and.
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.
B
I
think
I
think
this
helps
in
fact
you
might
have
mentioned
that,
and
I
forgot
and
I'm
still
thinking
before
you
you
mentioned
that,
so
that
that
does
reduce
the
complexity
a
little
bit.
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
B
So
then
sashi
going
off
on
the
sorry
I'm
on
the
epic
I
want
to
be
on
the
on
the
latest
spike.
B
Because
that
I
think
that
issue
here
is
showing
the
epic,
let
me
link
to
the
spike.
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
E
Yeah
that,
if
that
would
be
fine
to
do
that,
if
we
change
the
base
mix,
variable
then
we'll
just
reset
all
the
other
days,
and
then
it
now
gets
started
fresh.
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
Think
we
do
that,
don't
we
we
do
that
in
the
in
the
container
scanning
analyzer
itself,
we
we
publish
a
ubi
image,
actually,
four
images:
we
publish
trivia
and
gripe
and
trivia
and
graph
for
ubi.
A
B
One,
I
think,
sashi-
and
I
I
don't
know
if
we
talked
about
this
actually
in
this
context,
but
we
were
talking
about
it's
almost
like
you
start
pausing
the
docker
file
ourselves
to
understand
what
the
what
the
layer
build
is
right,
because
then,
if
you,
if
you're
building
four
images
or
two
images
in
your
in
your
container
and
they
both
use
the
same
base
image
so
say,
I
use
a
ruby
base
image
and
then
I
use
one.
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
B
The
philippines
philippe's
idea
is
to
have
an
include
for
for
for
an
list
in
the
night
list
that
you
can
just
say:
hey
never
worry
about
these,
but
those
are
cumbersome
to
create
right,
you've,
gotta
bash
in
cvs,
and
all
that,
although
you
could
script
it
like
you
export
things
and
anyway,
and
and
what
I
was
thinking
was
something
that
would
take
that
would
be
sort
of
built
into
the
workflow.
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
Yeah,
I
think
the
the
best
we
got
so
far
after
after
many
days
of
research
is.
Is
this
base
image
idea
and
did
you
think
about
how
to
solve
the
performance
problem?
Sashi,
no
pressure.
E
If
you
haven't,
but
so
I
have
to
purchase
in
my
mind,
one
minute
space
already
is
introducing
this
new
index
table
to
reduce
the
db
performance
overload,
because
currently
the
location,
fingerprint
and
the
location
data
is
is
inserted
as
a
json
and
filtering
it
using
a
field
inside
the
json
would
be
not
so
performant.
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
B
Which
is
undergoing
a
13-point
refactor,
starting
like
this
week
or
next
week,.
E
Because
so
I
was
thinking
if
we,
if
that's
going
to
happen,
maybe
we
could
take
it
back,
connect
yeah,
so
use
the
same
for
this
as
well.
Maybe.
B
A
A
B
No,
nothing,
nothing
obvious
obvious
to
me
just
a
matter
of
breaking
it
down
and
and
estimating
refining
and
estimating
okay
and
usually
sometimes
things
pop
up
when
you're
doing
that.
B
But
I
can't
I
can't
see
in
terms
of
timing,
though,
by
the
time
by
the
time
threading
sites
is
done,
doing
the
store
report
service
refactor.
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
All
has
it's
about
it's
about
10
points
as
well
and
depending
on
what
your
thoughts
are
same
on
the
roadmap.
You
could,
you
could
offer
some
help.
You
know
for
people
in
this
team
to
pick
that
up
instead
of
waiting
for
them,
but
either
way
somebody
we
need
to
do
that.
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.
B
If
you've
been
doing
an
amazing
job
with
minutes
by
the
way
sam,
let
me
let
me
let
me
just
put
some
links
here.
E
E
D
A
Makes
sense
to
have
those
triggers
in
place
would
what
I'm
not
understanding
fully?
I
guess
is
what
is
our
dependency
on
that
work,
for
what
we're
trying
to
do?
Are
we
trying
to
read
from
that?
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
Yeah,
so
I
think
it's
reasonable
for
us
to
take
that
piece
on.
You
know
we
have
a
strong
interest
in
having
that
trigger
created,
so
I
I
don't
mind
helping
out
and
creating
that
trigger.
You
know
the
trigger
that
we
need
to
to
solve
for
that
performance
problem.
A
A
B
B
So
I've
I've
pasted
two
of
those
issues
for
the
vulnerability
reads:
I'll
I'll
have
a
chat
to
the
threats
in
science
engineers
to
see
if
it
would
make
sense
to
do
that
before
doing
the
refactor,
because
then
we
could
paralyze
that
work
right
instead
of
doing
one
after
the
other
we'll
do
them
at
the
same.
B
It
hasn't
been
finished,
refining
and
it's
kind
of
hard
to
look
at,
but
I'm
looking
at
six
issues
at
least
give
it
another
average
of
two
points.
Probably
12
points
there,
so
it
would
probably
be
I'd.
Call
that
a
a
whole
engineer
dedicated
to
that
for
a
whole
milestone.
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
Yep,
exactly
okay,
so
yes,
sashi,
are
you
if
you're
clear
on
the
technical
solution?
Why
don't
we
document
it
really?
A
Well,
you
know,
let's
just
document
it
really
well,
let's
refine
it
as
much
as
we
reasonably
can
refine
it
at
this
point,
with
the
assumption
that
you
know
we're
starting
this
after
the
store
report
service
is
done,
refactored
being
refactored,
I
mean
it
might
be
a
little
bit
hard
to
fully
refine,
since
that's
not
done
so,
we
don't
know
what
we're
dealing
with,
but
let's
just
document
it
as
well
as
we
can
put
it
on
the
shelf
and
pick
up.
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.