►
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
Awesome
welcome
to
our
weekly
container
security
group
meeting.
First
of
all,
just
by
way
of
announcements,
annabelle
has
been
helping
us
out.
Ever
since
kyle
left
and
she's
been
splitting
her
time
between
dast
and
container
security,
we
had
just
barely
hired
a
backfill
for
kyle's
position.
That
person
is
actually
going
to
take
over
best
and
annabelle
is
going
to
be
the
permanent
permanently
assigned
to
the
container
security
team.
So
it's
been
a
few
months,
but
we
now
have
a
ux
resource.
You
know
a
ux
person
dedicated
to
container
security.
B
B
A
We've
got
a
full
agenda,
so
just
to
recap,
it
users
can
now
filter
by
specific
statuses,
instead
of
just
toggling
this,
mr
undermiss,
so
dismissed.
So
he's
continued
to
work
on
the
alert.
Dashboard
looks
like
he's
knocked
another
one
out,
so
we
we're
continuing
to
see
some
great
progress
there.
I
think
thanks
for
that
alexander,
so
probably
the
biggest
one
that
I
wanted
to
cover
today
was
just
to
formally
put
this
epic
through
planning
breakdown.
A
This
is
the
third
iteration
in
our
policy
work
and
this
one
is
mostly
front
end
based,
although
there
will
be
some
back
end
work
to
support
it,
we
did
a
design
review
on
march
2nd
so
about
a
month
ago.
A
I
didn't
want
to
put
it
into
planning
breakdown,
just
because
it
was
the
third
iteration
and
we
were
still
working
on
the
first,
so
I
didn't
want
to
get
too
far
ahead
of
things,
but
I
just
want
to
review
that
real
quickly
with
the
group
and
see
if
there
are
any
questions
or
do
we
feel
comfortable
that
it's
it's
clear
enough,
that
we
can
start
creating
the
implementation
issues
and
move
this
to
the
refinement
stage.
I'll
just
walk
through
this
real
briefly
just
to
do
a
quick
recap.
A
So
this
is
the
design
issue
for
it.
This
is
essentially
taking
what
we've
done
and
putting
a
ui
onto
it.
So
as
part
of
this,
the
policies
tab
in
the
threat,
monitoring
page
would
go
away
and
it'll
be
merged.
With
this
policies
page
right
now,
it
says
scan
policies.
This
would
be
changed
to
just
say:
policies
and
it'll
be
merged.
A
So
you
can
now
have
scan
execution
type
policies
here,
as
well
as
network
policies
all
in
the
same
ui
you'll
still
be
able
to
edit
your
policy
project,
but
by
default,
when
users
first
get
here,
oops
sure
when
users
first
get
here.
The
empty
state
is,
is
going
to
look
like
this,
so
we're
actually
not
going
to
require
them
to
set
a
policy
project
before
they
start
making
a
policy
if
they
go
and
they
click
new
policy
and
they
create
a
new
policy.
A
We
should
just
automatically
create
a
new
project
for
them
behind
the
scenes
and
link
it
up
and
associate
it
so
that
way,
we're
reducing
the
number
of
setup
steps
that
the
users
have
to
do
it,
and
it's
just
a
little
bit
automated,
so
the
first
time
they
create
a
new
policy,
we're
going
to
create
that
new
project
for
them.
If
it
does
not
already
exist,
or
they
can
click
edit
policy
if
they
want
to
set
it
initially
or
if
they
want
to
change
it
afterwards,.
B
A
B
Know
for
the
vulnerability
report.
We
have
a
number
of
different
states.
You
know
we
have
a
state
that
we
display,
but
they
don't
have
any
scanners
set
up
versus
a
state
that
we
display.
If
there's
no
vulnerabilities
returned
in
their
results
versus
just
one
generic
there's.
Nothing
here
state
it's
just
a
little
more
helpful
helpful
for
the
user
to
understand
what
their
action
is.
B
A
Yeah,
that
might
be
a
good
one
to
follow
up
with
annabelle
on
and
if
it
doesn't
make
it
in
here,
we
can
always
do
it
as
a
future.
Iteration
too.
C
And
same
for
the
for
I'm
curious
about
the
environment
column.
Are
we
going
to
be
able
to
create
policies
before
having
the
having
kind
of
projects
deployed
before
having
an
environment,
so.
A
A
A
So
we
already
have
this
sidebar
thing
for
our
policies
today
for
network
policies,
but
this
is
what
it
would
look
like
for
a
scan
execution
policy
if
you
click
on
on
one
of
that
type,
so
just
providing
some
really
high
level
details
about
it
and
then,
when
they
come
in
for
this
iteration
there
will
be
no
rules
mode,
it's
going
to
be
yaml
mode
only
and
actually,
as
I'm
looking
at
this
I'm
realizing.
We
probably
need
to
clean
up
these
mocks
just
a
little
bit,
but
basically
they'll
just
get
this
yaml
mode
here.
A
So
we
should
actually
remove
we're
trying
to
clean
this
up
for
the
network
policies,
but
we
should
remove
this
name
field
and
description
field
and
the
enable
button,
because
all
of
that
will
just
be
defined
here
in
the
yaml.
So
actually
we
should
remove
these
three,
but
otherwise
this
mock
is
stands.
You
should
just
be
able
to
select
the
policy
type
and
then,
if
it's
a
scan
execution
policy,
all
you
get
is
a
text
box
to
put
in
your
yaml.
A
So
that's
really
the
this
third
iteration
is
just
making
some
progress
to
let
the
users
edit.
This
in
a
in
a
user
interface,
rather
than
having
to
go
out
to
that
separate
project.
A
The
parser
yet
right,
correct
yep,
so
no
rules
mode,
we're
not
parsing
this
we're
just
you
know,
saving
the
yaml
exactly
as
they
enter
it
here.
Okay,.
A
A
So
are
there
any
looks
like
we
have
just
a
little
bit
of
cleanup
in
the
mocks
to
do,
but
is?
Are
there
any
questions?
Are
we
comfortable
starting
to
refine
this
and
break
it
down
into
implementation
issues?
On
the
back
end,
I
think
alexander's
already
done
the
front-end
breakdown.
D
The
one
thing
to
notice
like
to
add,
because,
like
we,
we
have
the
first
thing
merged,
so
we
have
something
that's
working,
but
during
the
review
we
had
to
limit
the
whole
policies
files
to
one
single
file
with
up
to
five
policies
in
that
file.
So
I
believe,
before
working
on
this
one,
the
back-end
side.
We
need
to
address
all
the
concerns
that
ci
team
had
just
to
make
sure
that
we
can
have
multiple
files
and
so
on,
so
that
that's
the
one
thing
that
will
block
us,
but
not
really.
D
A
Yeah
thanks
for
that
heads
up.
I
don't
think
that
should
block
our
ability
to
refine
this
one,
but
that
is
a
good
point
that
it
will
be
blocked.
While
we
finish
up
those
concerns
from
the
ci
team
yeah
thanks
for
that
reminder,
ellen.
A
D
Yeah,
so
I've
been
working
on
the
it's
a
second
iteration,
I
believe
so
project
level,
desk
and
execution
policies
for
schedule
scans.
I
prepared
the
initial
implementation
plan.
I
know
the
whole
thing
isn't
planning
breakdown.
I
I
wasn't
sure
why
so
I
I
wanted
to
first.
I
was
digging
in
trying
to
understand
what
we
need
to
do,
but
I
believe
we
already
did
planning
breakdown
long
time
ago,
when
we
were
working
on
on
the
initial
pocs,
but
anyway
I
prepared
notification
plan.
I
would
love
to
to
hear
some
feedback
or
questions.
D
The
only
questions
that
I
had
I
have
is
is
currently
is
this
one?
Maybe
I'll
can
I
share
my
screen?
Okay,
I
will
not
share
my
screen
now,
but
to
create
a
pipeline.
We
need
to
have
a
user,
some
kind
of
like
like
owner
of
the
pipeline,
who
triggered
that.
Usually,
when
we
have
a
pipeline,
it's
because
of
something
because
someone
hit
merge
or
someone
created
a
comment
and
so
on.
So
then
we
have
a
new
pipeline
created.
D
So
the
author
of
the
merge
quest
or
the
comet
will
actually
trigger
the
now
the
pipeline,
and
this
will
be
the
outer
of
of
that
pipeline
when
we
are
scheduling
pipeline.
It's
not
that
obvious,
because
currently
in
gitlab,
when
you
schedule
a
pipeline
and
not
like
normally
when
you
go
to
ci,
scheduled
pipelines
and
so
on
and
you'll
hit
start,
it
will
take
you
as
though,
as
the
creator
of
of
the
schedule,
but
in
this
kind
of
policies
we
don't
have
that
concept.
D
We
don't
have
like
the
owner
like
we
could
have
something
like
that
by
taking
the
user
that
actually
triggered
the
comment
that
ended
up
like
that
updated
the
policy
or
we
can
specify
the
certain
user
that
we
want
to
use
to
be
the
the
owner
user
of
the
pipeline.
We,
I
see
your
question
sam
does
github
have
any
kind
of
system
user,
I'm
not
sure,
probably
not
because
usually
it
will
normally
would
have
like
some
kind
of
service
account
that
will
be
responsible
for
doing
that.
We
don't
have
something
like
that.
D
Now
that
that's
what
I
think
I
haven't
seen
anything
so
I'll
need
to
take
a
look.
So
I
had
three
ideas.
The
first
one
allow
users
to
specify
user
for
the
in
the
policy,
which
is
very
simple,
we'll
just
add
additional
key
to
the
yaml
file
with
user
and
then
we'll
store
the
yaml
file
like
the
username.
D
The
second
option
would
be
to
specify
it,
but
on
the
ui
level,
when
we
are
specifying
which
project
is
the
like
scan
execution
policy
project
for
offer
for
selected
project
now,
so
that's
the
other
option
and
the
third
option
is
to
get
actually
the
username
from
the
last
comment
that
was
used
to
to
save
given
policy,
I
don't
know
which
would
be
the
best
one.
D
I
would
vote
for
the
second
option,
because
this
will
this
allow
us
to
to
have
some
kind
of
validation
of
the
of
the
username
and
so
on,
but
the
third
one
would
be
the
easiest
in
terms
of
like
for
the
user
experience,
it
will
be
the
best
because
they'll
not
think
about
about
assigning
the
user
to
be
an
owner.
But
to
be
honest,
that's
something
that
we
need
to
consider
what
to
do.
A
Yeah
I
so
I
don't
know
if
this
is
the
same
as
option
three
so
correct
me
if
it
is
the
same,
but
it
would
be
really
nice
if
the
user
did
not
have
to
think
about
this.
I
would
expect
that
the
user
who's
merging
the
policy
into
the
project
I
mean
they're,
the
one
who
created
the
policy
so
they're
the
one
who's
creating
the
pipeline.
So
I
would
expect
that
they
would
be
the
author
of
the
pipeline.
D
C
Just
one
thing:
I
think,
if
you
go
like
that,
we
should
write
something
kind
of
information,
so
the
user
know
what's
happening
that
his
name
is
going
to
be
showing
up
in
pipelines
that
they
didn't
trigger.
Just
for
the
sake
of
clarity
for
the
user
and
that
that's
the
reason
I
would
like
option
one.
I
like
option
three
but
option
one
for
me.
It's
very
clear:
we
could
default
the
user
as
the
project
owner
or
the
user.
That's
creating
the
policy.
So
it's
very
clear
of
what's
happening.
A
D
D
A
D
We
need
to
have
a
pipeline
because,
like
the
whole
thing
I
mean
creating
vulnerabilities
in
database,
it's
only
triggered
in
the
pipeline.
If
we
want
to
have
it
outside
of
the
of
the
pipeline,
then
we
will
need
to
rework
lots
of
things,
so
we
need
to
have
have
a
policy,
I
believe
what
you're
referring
to
about
setting
something
to
be
read-only.
D
I
remember
that
we've
discussed
that,
because
on
on
demand
scan,
I
believe,
that's
team
is
also
working
on
schedule
on
demand
scans
and
we're
thinking
if
we
should
somehow
show
our
policies
like
our
like
on-demand
scheduled
scans
from
policies
in
that.
In
that
view,
and
I
believe
we
ended
up
with
thinking
about
read-only
solution,
but
I
believe
that's
not
the
case
here
as
we're
trying
to
understand
how
to
to
get
the
user,
how
to
get
the
out
owner
of
the
policy
and
owner
of
the
pipeline.
D
A
C
Now
so
alum,
I'm
sorry
if
your
discussion
is
a
little
bit
unrelated,
but
would
you
mind
just
say
sharing
if
the
audacity
is
working
on
the
on-demand
scanner,
also
relying
on
the
pipeline
or
are
they
doing
something
different?
Do
you
know
that
by
any
chance.
D
I
don't
know,
but
assuming
what
they're
working
on
right
now
in
terms
of
like
the
whole
on
demand
scans,
I
believe
they'll
reuse,
what
they
have
so
creating
a
new
pipeline
with
the
with
the
scan.
So.
D
A
So,
looking
back,
I
think
we
decided
to
hide
it
entirely.
So,
on
the,
if
you
go
in
to
view
your
list
of
scheduled
scans
in
get
lab
it,
it
wasn't
even
going
to
show
up
there
just
because
it's
kind
of
behind
the
scenes
that
this
is
a
scheduled
scan.
You
know,
and
it's
confusing
to
have
it
appear
in
both
places,
and
then
you
can't
edit
it
in
the
one,
and
so
I
don't
know
that
we
need
to
worry
too
much
about.
D
A
Schedules
view,
and
I
said
I
could
go
either
way.
You
know
we.
If
we
do
show
it,
then
it
needs
to
not
be
editable
and
then
annabelle
said
she's
leaning
towards
a
no
not
showing
it,
and
she
lists
her
reasons.
So
we
could
revisit
that
decision.
You
know
derek
shares
that
same
idea.
You
know,
let's
not
show
it
in
the
scheduled
pipelines,
so
I
think
that's
where
we
landed
as
far
as
a
decision
there
was
to
not
show
it.
A
Yeah
I'll
copy
that
to
the
description
of
of
the
I'll
copy
this
into
the
epic,
so
that
we
have
it
all
in
one
place
after
the
call.
A
No
worries-
I
I
forgot
it
as
well
when
I
created
this
epic,
so
yeah.
I
I
think
in
this
case,
where
they're
not
even
gonna,
see
that
that
makes
me
want
even
more
to
not
have
the
user
specify
the
author.
You
know,
that's
just
gonna
be
one
extra
step
and
they
don't
even
know
that
we're
creating
a
scheduled
pipeline.
A
You
know
it's
a
scheduled
scan,
not
a
scheduled
pipeline
as
far
as
they're
concerned.
So
if
we
can
hide
that,
I
guess
my
biggest
requirement
is:
let's
just
hide
that
from
the
end
user.
So
whatever
author
we
pick,
let's
make
it,
so
they
don't
have
to
input
that.
D
Okay,
so
the
one
thing
that's
left
here:
it's
actually
at
the
end
we
will
have,
will
it
will
not
be
visible
here
and
the
cicd
scheduled
pipelines
would
not
be
visible
here.
But
since
we
are
triggering
a
new
pipeline,
it
will
be
visible
here
because
it
will
have
like
new
number
and
so
on
and
we
will
have
to
have
the
trigger.
D
But,
as
you
said,
if
we'll
reuse,
the
author
of
last
comment
in
the
policy
project,
then
then
it's
fine,
we'll
just
have
have
that
person
here
and
that's
it.
C
Have
we
ever
considered
like
having
like
a
bot
user
added
to
the
project?
I
know
that's
a
little
bit
outside
of
the
scope,
but
if
we
start
moving
forward
with
having
automatically
triggered
pipelines,
it
might
be
good
to
have
like
a
bot
user
created
to
a
project
with
a
certain
level
of
privileges.
So
then
we
can
assign
to
this
type
of
jobs,
and
it
would
be
it
would
reduce
source
of
ambiguity
instead
of
adding
someone
else's
name
over
there.
Sorry
for
being
being
picked
on
this.
A
Yeah,
I
agree,
I
think,
that's
a
great
idea-
it's
probably
hard
to
do
that
right
now,
because
we
users
still
have
access
to
that
members
tab,
so
they
can
add
and
remove
people
from
the
project,
but
eventually
we'll
want
to
hide
away
that
members,
tab
and
kind
of
manage.
You
know
have
git
lab,
manage
the
permissions
in
that
project,
rather
than
letting
them
do
anything,
and
that
might
be
a
good
time
to
introduce
a
bot
user.
C
So
alan
for
now
I
think
the
easiest
way
that
I
would
suggest
it's
just
use
the
project
owner.
So
then
you
don't
have
to
keep
querying
and
updating
the
table
all
the
time.
Every
time
a
user
updates
some
some
sections
over
there.
That's
yeah.
A
Okay
and
then
this
last
one,
I
posted
a
comment
comparing
the
different
implementation.
Pro
approaches
that
have
been
proposed
for
production
container
scanning
a
like
for
us
to
move
forward
using
starboard.
Are
there
any
concerns
about
moving
forward
with
that,
or
at
least
doing
a
research
spike
to
to
make
sure
that
that
will
work
for
us.
A
Okay
sounds
good.
Well,
I
will
I'll
tag
thiago
in
that
one
as
well
and
we'll
see
if
we
can
get
that
in
the
schedule.