►
From YouTube: Protect:Container Security group discussion 2022-04-05
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
A
The
group
level
security
policies
feature
flag
is
up
on
staging
and
alan
recorded
a
small
demo
of
how
to
use
the
graphql
api
with
group
level
security
policies.
So
we've
got
some
good
videos
coming
out
all
of
that's
behind
a
feature
flag,
but
if
you're
able
to
turn
on
the
feature
flag,
you
can
actually
start
using
that
today
on
the
back
end,
if
you're
anxious
for
that
feature,.
A
So
yeah,
the
only
other
topic
we
have
for
today,
oh
good,
neil
euron,
is
the
carryover
from
our
one
on
one
we're
looking
through
our
priorities,
issue
and
realizing
that
we
don't
have
a
great
way
to
see
how
big
those
are
right
now
at
a
glance,
and
that
would
actually
help
a
lot
on
my
end
with
prioritization.
A
Just
because
you
know
I
make
my
best
guess
as
I
go
through
those,
but
really
prioritization
is
somewhat
of
an
roi
estimation
right.
How
much
is
it
going
to
benefit
provide
value
to
the
users
and
our
customers
versus?
How
much
is
it
going
to
cost
us
to
build?
A
There
are
some
other
considerations
that
go
into
like
you
know
doing
one
thing,
maybe
a
prerequisite
for
another
thing,
or
you
know
there
can
be
some
strategic
things
that
factor
in,
but
mostly
that
sort
of
an
roi
calculation
is
what's
going
on
in
the
back
of
my
mind.
A
But
I
don't
want
this
to
be
a
huge
level
of
effort,
because
we
already
go
through
and
refine
everything
in
great
detail,
and
it
would
be
a
lot
of
work
to
go
refine
everything
this
early
on.
When
we
haven't
even
figured
out
all
of
the
details,
so
I
just
wanted
to
open
it
up
for
discussion
and
see
what
your
thoughts
are.
B
So
we
have
that
spreadsheet
that
we've
used
in
the
past
for
doing
t-shirt
sizes.
It
also
gives
us
a
sort
of
consistent
result,
I
guess
or
arguably
consistent,
and
maybe
it's
something
that
you
and
I
can
help.
B
A
So
yeah
I
mean
we
don't
have
to.
I
I'm
very
cautious
of
you
know
making
this
too
analytical,
because
our
inputs
are
going
to
be
just
rough
estimations
anyway,
and
you
know,
there's
definitely
a
risk
of
putting
too
much
confidence
in
those
estimations
or
making
big
decisions
off
of
them
when
they
really
are
just
estimations,
but
if
we
have
an
easy
way
to
get
rough
t-shirt
sizes,
I
think
that
would
be
really
nice.
A
Part
of
this
came
out
of
a
an
epic
that
alexander
refined
and
it
came
out
that
the
size
was
a
lot
larger
than
I
originally
expected
it
to
be,
and
so,
as
a
result,
I
moved
it
down
on
the
priority
list,
because
it
was
a
lot
more
work
to
get
done.
You
know,
so
we
might
adjust
priorities
based
off
of
this.
If
we
had
good
t-shirt
sizes.
C
Here
our
t-shirt
sizes,
basically
like
the
same
as
a
weight,
so
we
kind
of
could
do
that.
The
thing
is
that
you
can't
add
weights
to
epics,
and
you
know
epics
are
usually
so
big
that
I
feel
like.
You
can't
really
estimate
the
size
of
them.
B
Yeah
this,
this
is
what
we
used
before.
It
helps
think
about
it.
It's
not
super
precise,
but
for
for
what
it
is,
it
should
lend
us
on
the
answer
that
sam
needs
to
prioritize
so
given,
given
the
roles
are
the
the
the
projects
or
the
initiatives,
and
then
you
break
up
the
effort
into
three
things
like
how
well
defined
it
is
the
the
effort
that
you
think
that
that
will
take
and
the
complexity
and
then
the
through
the
magic
of
spreadsheets.
B
These
choices
get
get
calculated
into
me
to
a
number
that
you
can
look
at
regarding
this
is
medium
or
small
or
large
and
yeah
epics
don't
have
a
weight,
but
you
you
can.
We
can
use
that
priorities
issue
to
put
that
number
in
there
and
say
estimated
effort,
and
I
I
think
if
we,
if
we
do,
that,
we
should
agree
that
you
know
that
is
for
for
the
purpose
of
that
prioritization.
B
Only
that
way
that
that
would
need
to
be
re-refined
once
we
do
right,
so
we
know
better
when
we
actually
doing
the
thing.
What
do
you
think
of
this?
D
D
I
don't
know
when
this
occurred
or
if
it's
a
regular
cadence,
but
we
did
this
across
all
the
analyzer
groups
and
had
front
end
and
back
end
and
then
ended
up
with
that
calculation.
We
had
that
same
like
that.
Second
tab
was
the
calculated
value
based
on
the
the
combination,
and
it
was
extremely
effective
in
terms
of
understanding
where
we're
at
like.
D
D
B
I
don't
remember
either,
but
it
is
like
it
is
meant
to
to
spit
out
a
point
output
that
then
you
can
they.
You
can
throw
that
against
your
team
velocity
now
it
it
comes
with
caveats
right,
because
different
teams
will
have
different,
velocities
and
and
even
even
between
front
end
and
back
end.
We
might
be
calculating
velocity
different,
which
is,
which
is
why
I
would
favor
us
you
know,
being
consistent
in
there.
B
D
So
some
more
back
story
to
our
conversation
is
with
alexander
being
the
only
front
end.
It's
it's
hard
to
look
at
the
front,
end
list
of
items
and
really
anticipate
how
far
down
like
row
four
would
be.
You
know
one
and
two
are
clear:
we've
already
been
thinking
about
those,
but
then
the
fours
and
the
fives
in
the
list,
not
real
certain
when
we're
actually
gonna
get
to
accomplish
those.
You
know
that's
at
the
mercy
of
how
big
stuff
in
the
middle
is.
D
How
big
that
stuff
is
how
much
back
end
is
actually
anticipated,
which
is
sam's
point.
I
think
the
analysis
alexander
did
us
surfaced
that
there's
actually
more
back
end
than
we
realized,
and
so
that
was
additional
information
that
was
important,
informative.
B
The
the
yeah,
the
the
input
is,
the
letters
right.
We
we
don't
have
the
the
sml
as
an
output
of
that
spreadsheet.
We
could
come
up
with
a
range
that
says
all
right
up
to
10
is
small
10
to
20,
medium
20
and
above
is
large,
and
then
we
throw
that
on
the
on
the
priorities
issue,
but
should
we
do
then,
should
we
keep
separate
the
front-end
effort
and
the
back-end
effort.
D
Can
you
I
don't
you
don't
need
to
share
again,
but
the
d
e
c
that
that
d,
for
definition,
was
really
crucial,
as
part
of
the
conversation
goes
because,
like
the
less
something's
defined
the
more
inflated,
the
estimate
is
going
to
be
there's
way
more
variability
or
variance
that
we
need
to
anticipate
when
something's
defined
as
being
small,
there's,
not
blood.
I
give
you're
going
to
see
a
lot
less
fluctuation
in
the
weights
where
you
can
see
in
the
sheet.
The
the
find
column
is
largely
dry.
D
A
One
messing
with
our
actual
numbers,
because
you
know
just
a
topic
that
we
have
made
may
have
discussed
more
is
likely
to
show
up
as
better
defined,
whereas
something
else
you
know
we
could
talk
about
it
just
a
little
bit
more
and
then
it
would
be
well
defined,
but
an
absence
yeah
question
it's
not
and
anyway,
so
it
gets
tricky.
B
Yeah,
I
think
I
think
you
don't
you
you,
you
know
if
you
don't
like
what
you
see
there
and
you
think
like
it
helps
as
a
start
of
a
conversation.
If,
if
somebody
gets
a
result
that
they're
not
expecting
you
can,
you
can
dig
down
into
okay,
looks
like
it's
large
for
well-defined.
Let's
have
a
conversation.
Maybe
we
can
take
that
down
to
a
better
defined
thing
and
that'll
help
with
the
estimation,
but
I
to
try
and
find
the
balance.
B
I
would
like,
if
I'm
doing
this
I'll
I'll,
go
with
what
I
know
and
then
wait,
publish
the
results
and
then
wait
for
to
be
asked
to
say:
hey.
Can
we
have
a
better
look
at
this
so
sure?
Let's
because
otherwise,
if
you're
trying
to
ask
too
many
questions
and
go
around
you're
kind
of
starting
doing
the
work
already
and
it
defeat
defeats
the
purpose
of
having
something
quick.
B
So
new,
the
the
spreadsheet
on
on
the
second
tab,
has
a
link
to
the
dex
scoring
document.
It's
got
yeah.
It
has
words
of
wisdom
about
how
to
how
these
things.
A
All
right
well,
it
sounds
like
we
want
to
do
this,
maybe
I'll
drop.
How
do
we
want
to
do
this?
Do
we
want
to
do
this
async?
Should
I
drop
a
30
minute
meeting
on
our
calendar
between
myself
and
the
key
managers
or.
B
I'm
happy
to
do
async
if
we
think
we're
gonna
go
back
and
forth
too
many
times.
We
can
do
the
first
one
synchronously,
but
I
I
was
going
to
volunteer
to
create
a
spreadsheet
with
all
the
items
in
our
priorities
issue
and
then
neil
and
I
can
come
in
on
the
respective
areas,
populate
them
and
the
engineers.
If
they're
interested
they
can,
they
can
come
and
have
a
look
it'll
be
open
to
everyone.
B
A
Well,
that
is
the
big
risk
of
this
right
is
that
it
becomes
a
time
sink
or
yeah,
and
you
know
we
don't
want
to
spend
too
much
time
on
this,
because,
unless
we're
going
through
a
full
refinement,
these
are
just
lightweight
estimations
and
we
have
to
take
it.
The
output
with
a
grain
of
salt,
just
as
much
as
that's
it,
you
know,
have
a
grain
of
salt
going
into
the
input
right,
pretty.
C
I
think
it's
like
there's
some
things
that
are
easy
to
estimate
where
you
know
like
it
might
be
well
understood.
How
did
you
implement
the
future,
but
there's
a
lot
of
things
where
we
might
have
no
idea,
and
it's
like?
Oh,
if
we
have
no
idea
just
assume
it's
large.
I
guess
I
don't
know.
D
D
D
Oh,
my
god,
so
you
know
I
earlier
I
threw
out
if
we
just
had
a
range
like
within
a
milestone,
one
to
two
milestones
and
more
than
two
milestones.
That's
sml
and
we
just.
A
B
Yeah,
I
think
I
think
it's
kind
of
risky
putting
milestones,
because
if,
if
I
say,
if
I
say
small
or
medium,
people
might
have
different
ideas
of
what
that
could
mean
in
terms
of
milestones,
but
when
you
start
putting
milestones
in
that
priorities
issue,
it
kind
of
I
think
it's
easier
to
take
that
at
face
value
and
and
start
start
creating
an
expectation,
not
not
everybody
that
sees
that
issue
is
in
the
in
the
inner
circle
of
our
team
and
and
knows
that
it
should
be
taken
lightly
and
hey,
say
one
milestone
might
actually
be
two.
B
If
we
say
five,
it
could
actually
be
three.
I'm
I'm
happy
to
try,
but
I
would
I
would
be
careful
and
and
keep
an
eye
out
to
mismatch
the
expectations.
B
C
Yeah,
the
other
thing
is
that
we
might
not
really
know
how
many
engineers
are
going
to
be
working
on
the
epic
like
a
lot
like
issues
go
on
the
board
and
people
grab
whatever
they
want,
and
so
sometimes
there
might
be
two
or
three
engineers
working
on
one
epic.
Sometimes
there
might
be
just
be
one,
you
know,
that's
a
good
point.
We
don't
really.
B
D
Yeah,
I
so
for
issues
we
do
relative
sizing
against
previous
completed
issues
right.
We
have
an
idea,
I
don't
know
if
we
have
enough
data
to
do
that
at
a
project
at
an
epic
level,
but
that
could
be
another
idea.
Does
this
feel
like
the
project,
a
project
b,
type
of
thing,
and
we
have
some
sort
of
reference
list
of
projects
that
have
a
t-shirt
size
and
then
it's
more
about
the
complexity.
A
A
little
bit
hard
to
go
back
retroactively,
because
now
that
we've
done
it,
you
know
that
we
talked
about
that.
You
know
defined
aspect.
The
defined
aspect
changes
once
you've
actually
completed
it,
so
I
think
it
might
be
better
just
to
track
it
going
forward
and
say:
oh,
we
estimated
this
at
an
xl,
and
this
is
what
it
came
out
as
yeah.
B
Yeah,
we
can
always
go
back
to
the
spreadsheet,
because
we
we
do
delete
the
rows
from
the
issue
as
we
as
we
complete
them.
So
we
wouldn't
have
that
the
history
tell
you
what
I'm
happy
to
create
a
blank
spread
spreadsheet.
Do
you
want
all
the
items
sam
or
should
we
limit
to
like
the
top
five
in
each
can't
agree.
B
A
B
I
added
something
now
to
the
agenda:
it's
on
the
same
topic
since
we're
going
to
modify
the
priorities
issue
to
have
the
size
estimate
in
threatening
sites.
We
recently
we
had
two
privacy
tables
and
it
was
kind
of
confusing
having
two
priorities
out
of
the
two
top
ones,
which
one
is
the
top
top
in
container
security
is
not
as
bad
because
you
took
the
effort
sam
of
putting
the
number
of
engineers,
so
it
helps
it
helps
with
that.
B
But
I'm
wondering
if,
if
we
could
give
that
a
go,
if
if
what
it
would
look
like,
if
we
actually
unified
that
and
make
one
larger
table.
A
Yeah
we
could,
I
can
definitely
see
where
that
would
be
easier
from
an
engineering
perspective.
Just
as
a
reminder,
the
reason
we
split
it
out
in
the
first
place
was
because
this
one
goes
all
the
way
back
like
a
year
or
more
to
when
we
changed
from
defend
to
protect
and
scott
said.
You
know,
I
want
50
on
security
orchestration,
that's
right,
25
to
50
on
container
scanning,
and
I
want
0
to
25
on
container
host
security
right.
B
The
other
reason,
sam
that
new
brought
up-
I
thought
it
was
good-
is
that
alexander
stays
like
isolated
in
there
and
sometimes
frontended
is
needed
in
in
these
other
initiatives,
and
it's
hard
to
balance.
You
know
so
it
creates
that
pro
okay
is,
is
alexander's
top
priority
the
same
as
security
orchestration's
top
priority.
A
Yeah
so
for
alexander,
we
actually
created
that
front
end
table
at
the
bottom,
which
basically
is
a
mesh
summarized
vision
for
him,
because
he's
just
one
engineer
so
there's
no
need
to
like
split
it
out.
I
mean
he
has
to
help
with
everything
right.
So
that
really
was
the
intent
of
that
table
at
the
bottom
was
so
that
alexander
had
one
place
to
go
to
with
everything
on
it,
but
if
it's
causing
problems
for
you
on
the
back
end
or
if
you
would
rather
combine
it,
I
I'm
certainly
happy
to
do
that.
A
Selfishly
it's
a
little
bit
easier
for
me
to
prioritize
inside
of
a
category
because
it's
yeah
to
compare
you
know.
Security
orchestration
features
to
each
other,
whereas
comparing
the
value
of
a
security
orchestration
feature
to
contain
our
scanning
feature,
it's
a
little
bit
harder,
but
I'm
willing
to
do
that
comparison.
If,
if
we
need
to
it's.
B
What
about
if
we
kept
the
security
approvals
separate,
because
that
one
is
a
one-man
band
anyway,
right
right,
it's
completely
isolated
for
for
for
the
other
categories
in
alexander,
if
we're
gonna,
add
t-shirt,
size
estimates
to
the
rows
anyway,
I
don't
quite
know
how
that
would
work.
If,
if,
if
we
have
separate
right,
do
we
not
put
the
estimate
on
alexander's
or
only
put
in
the
front
end
table
and
don't
put
it
on
the
on
the
other
tables.
A
A
suggestion
we
have
just
one
unified
one
all
together
and
now
you
have
to
pass
through
and
figure
out,
which
is
front
and
back
end.
In
the
past
we
had
the
front
end
table
so
that
alexander
had
just
one
place
to
go,
but
you
know:
do
we
have
a
back-end
table
as
a
mirror
table
and
a
front-end
table?
We
have
just
one
table
so
again,
I'm
not
too
picky.
B
E
Yeah,
that's
fine
I'll,
open
up
a
poll
on
the
issue
and
let
me
let
me
create
the
comment:
okay,.