►
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
Hi,
I'm
sam
white
and
I'm
the
senior
product
manager
for
the
container
security
group.
Today,
I'm
going
to
be
doing
our
release
kickoff
for
the
1310
release,
but,
first
of
all,
and
more
importantly,
I
just
want
to
cover
a
little
bit
of
our
strategy
for
the
security
orchestration
category
that
we
have
and
talk
about
what
we're
working
towards
and
how.
What
we're
doing
in
1310
is
our
first
iterative
step
towards
our
long-term
vision.
A
Our
long-term
vision
for
policies
is
to
allow
users
to
come
in
and
create
scan
execution
policies,
and
these
scan
execution
policies
define
when
a
scan
is
run
and
enforce
that
scan
to
be
run
in
a
way
that
the
developers
and
maintainers
on
a
normal
project
are
not
able
to
change
or
disable
it.
This
is
important
because
today,
developers
and
maintainers
have
full
access
to
that
gitlab
ci.yaml
file,
and
so,
if
a
user
is
trying
to
enforce
the
scan
to
be
run
as
part
of
the
pipeline,
it's
a
lot
of
work.
A
A
If
this,
then
that
english
sentence
style
policy,
where
you
can
come
in
and
say
you
know,
if
a
pipeline
is
run
for
the
master
or
default
branch,
then
I
want
to
require
a
das
scan
to
run,
for
example,
with
your
specified
scan
profile
and
site
profile,
and
you
could
also
configure
this
to
run
on
a
given
schedule
and
enforce
it
to
happen
as
well,
so
on
a
daily
or
weekly
basis.
If
you
want
to
make
sure
that
a
scan
is
run,
you
could
use
these
policies
to
do
that.
A
Typically,
in
an
organization
the
application
security
team,
or
in
some
cases
the
compliance
team
would
be
the
one
writing
these
policies
and
forcing
them
from
the
organization
and
making
sure
that
these
scans
happened
in
a
way
that
the
maintainers
and
developers
on
an
individual
project
were
not
able
to
disable
it
down.
The
road
we
want
to
add
support
for
all
of
the
different
scan
types,
all
of
the
different
scanners
that
we
have
here
in
gitlab,
and
we
also
want
to
have
the
ability
to
support
full
policy
change
logs.
A
A
All
of
this
is
a
lot
of
work,
and
it's
not
very
iterative
when
you
look
at
this
end
state,
so
we
wanted
to
break
this
down
in
a
way
that
we
could
get
something
out
to
users
rather
quickly
that
they
could
actually
use
and
take
advantage
of
in
this,
you
see
that
we
allow
both
a
rule
and
a
yaml
mode
editing.
So
if
users
want
to
edit
the
yaml
for
these
policies,
that's
possible.
A
Even
though
all
of
this
user
interface
is
nice
and
easy
to
use
for
the
first
iteration
we're
planning
to
just
solve
the
problem
of
separating
out
those
duties
to
allow
those
security
teams
to
write
these
policies
in
a
way
that
developers
can't
change
them.
So
when
we
focus
just
on
that,
our
initial
iteration
is
going
to
be
much
much
more
simplistic.
A
A
In
that
security
policy
project
they
can
now
have
a
separate
set
of
users
who
have
developer
and
maintainer
permissions.
So
they
have
that
separation
of
duties.
They
can
control,
who
can
propose
and
commit
and
merge
in
changes
to
those
policies
and
again
in
that
yaml
in
that
project
they
can
actually
define
what
those
policies
look
like.
A
It
also
comes
with
a
huge
advantage
in
that,
because
we're
storing
this
in
a
repository,
it
lets
us
quickly
add
support
for
the
other
scanners
much
more
quickly
than
we
could
if
it
were
stored
in
our
gitlab
database
or
in
some
other
data
store.
So,
although
we're
planning
to
support
dashed
policies
out
of
the
gate
for
1310,
if
we
wanted
to
add
support
for
sas
or
any
of
the
other
scanning
capabilities
that
we
have
in
gitlab,
it
opens
the
door
for
us
to
do
that
rather
quickly.
A
So
it
will
be
an
iteration
path
towards
there,
but
for
now
we're
starting
with
this
super
minimal
step
in
1310,
so
that
we
can
get
something
out
the
door
and
start
getting
feedback
again.
If
you
do
have
any
feedback
to
share,
please
feel
free
to
add
it
to
that
epic,
and
we
look
forward
to
hearing
from
you.