►
From YouTube: CNCF Security TAG Regular Meetings 2021-10-06
Description
CNCF TAG Security Regular Meetings 2021-10-06
A
B
A
A
All
right
folks,
thank
you
so
much
for
joining
us.
I've
pasted
our
meeting
notes
in
chat,
quick
reminder.
This
meeting
is
being
recorded
and
posted
to
youtube
live.
Your
participation
in
these
meetings
is
an
agreement
to
abide
by
the
cloud
native
security
code
of
conduct
which
can
be
found
within
the
repo.
I
need
at
least
one
person
to
volunteer
as
scribe
to
ensure
all
actions
and
primary
content
discussed
is
recorded
in
the
written
notes
and
can
be
referred
to
later.
For
those
that
are
unable
to
attend.
A
Do
I
have
any
volunteers:
I've
got
ash
and
axel
awesome.
Thank
you.
So
much
for
existing
members
and
working
group
reps,
please
remember
to
include
your
organization
and
company,
along
with
the
working
group
that
you're
involved
with
as
a
reminder,
because
we
have
a
presentation
today,
we
will
not
be
going
over
updates
and
I'd
like
to
try
to
give
everyone
as
much
time
back
as
possible,
because
cubecon
and
cloudnativesecuritycon
are
next
week.
So
thank
you,
everyone
for
joining
us
today.
I'm
gonna
turn
it
over
to
simon
who's,
going
to
talk
to
us
about
cartographos.
D
E
E
B
Hey
this
is
robbie
glenn.
Sorry,
I
joined
a
little
late.
Apologies
for
that.
So
why
do
we
need
a
new
map
right?
We
have
the
landscape.
We
have
the
trail
map.
Well,
the
landscape
is
is
pretty
daunting
if
you're
just
getting
into
this
space.
There's
a
lot
going
on
and
it's
hard
to
maybe
know
where
to
start.
B
The
trail
map
is
very
kubernetes
centric
and
it's
very
from
a
technical
capability
perspective,
it's
very
useful
for
a
team
getting
their
hands
dirty
or
even
really
growing
their
their
acumen
with
kubernetes
and
with
the
the
suite
of
of
products
around
it.
But
we
wanted
to
expand
the
focus
of
a
map
to
include
all
aspects
of
cloud
native
cncf
landscape
to
really
provide
a
journey
from
an
organization's
perspective.
B
So
we
wanted
to
provide
something
that
could
be
consumed
by
like
leaders
of
an
organization
so
that
they
could
leverage
the
experiences
of
a
team
that
might
have
you
know,
taken
a
journey
on
the
trail
map
and
gained
some
experience
there.
Maybe
even
you
know,
we
want
to
be
our
audience
to
include
business
leaders
who
are
preparing
for
the
organizational
change
that
they'll
have
to
go
through
over.
B
You
know,
maybe
the
several
years
that
this
journey
takes
and
so
that
you
know
engineering
teams
can
see
what's
on
the
road
ahead,
what
they
need
to
be,
you
know,
training
for
and
getting
ready
for
to
and
also
you
know
which
tools
are
going
to
provide
the
biggest.
You
know
return
of
investment
at
each
stage
say
of
the
journey.
E
D
So
many
organizations
do
start
their
cloud
native
journey
with
no
real
framework
on
how
to
adopt
these
new
applications
and
platforms,
as
robert
has
illustrated
for
us.
The
cloud
native
trail
map
and
cloud
native
landscape
provide
very
simple
paths,
but
certainly
not
comprehensive
enough,
and
as
the
landscape
grows,
we
did
want
to
provide
a
framework
for
how
people
may
be
able
to
adopt
cloud
native
technology
and
again
when
starting
down
the
cloud
native
journey.
A
common
response
from
people
is:
where
do
I
start,
and
what
do
I
take
on
next?
F
F
So
what
we
assume
is
that
if
you
are
entering
the
cloud
native
maturity
model
or
looking
at
it,
you've
already
decided.
You
want
to
go
cloud
native,
you've
already
decided
you're
into
open
source
and
that's
the
future
of
your
business
they.
So
then,
at
that
point
you
start
these
levels
and
the
first
level
is
you're
just
building
out
your
baseline
implementation
you're
in
pre-production.
F
You
then
go
into
your
operation
phase,
which
is
level
two
where
you
have
established
your
your
foundation
and
you're
moving
your
applications
into
production
level.
Three
is
where
you're
scaling.
So
you
know
what
you're
doing,
but
now
it's
time
to
build
like
the
repeatability
around
your
infrastructure,
your
applications,
level
four
is
improving.
So
that's
where
we
spent
time
focusing
specifically
on
security
policy
and
governance.
F
However,
those
things
are
built
into
all
of
the
phases
of
the
maturity
model
which
we'll
get
into
in
a
moment,
and
then
the
final
phase
is
optimization
and
that's
where
you
are
really
good
at
cloud
native,
but
you
have
to
go
back
and
look
and
go.
Maybe
we
didn't
make
the
right
decision
here?
How
can
we
optimize?
How
can
we
make
it
better?
F
F
One
of
the
things
we
realized
when
we
were
take
going
through
all
the
different
maturity
models
and
pulling
them
together
and
then
considering
our
experience
as
well
is
that
we
had
four
common
themes.
So
we
had
themes
of
there's
certain
ways.
People
need
to
work
with
cloud
native
and
they
need
to
change
the
way
they're
thinking
in
the
way
their
skill
sets
that
they
have
there's
obviously
certifications
you
can
get
and
all
of
that
within
the
cncf
community.
F
Then
we
looked
at
process
so
or
that
came
out
as
a
theme
where
it's
like
there's
a
lot
of
process
that
needs
to
be
put
in
place.
We
put
it
incorporated
the
whole
shift
security
as
far
left
as
possible
and
that
messaging
in
our
process,
then
policy,
so
obviously
with
internal
policies,
external
policies,
there's
companies
that
have
huge
compliance
requirements
and
mandates.
F
E
E
Let's
discuss
the
kubernetes
attack
service.
There
are
a
total
of
10
attack
vectors
to
address
from
the
container
down
to
the
network.
How
do
we
secure
kubernetes?
We
start
by
identifying
the
security
threats
in
the
kubernetes
architecture
and
the
potential
threats
associated
with
it.
You
need
to
think
about.
How
can
I
reduce
the
attack
of
that
surface?
Kubernetes
can
be
a
complex
system
in
order
to
mitigate
the
blast
radius
and
reduce
the
attack
vector.
We
want
to
do
things
like
use
minimum
images.
E
E
So
when
we
talk
about
security
and
the
mature
model
that
we're
showing
over
here,
there's
a
lot
to
it,
there's
a
lot
beyond
the
scenes
that
there's
many
different
phases
levels
as
we
talked
about
before
that
a
part
of
this,
and
so
our
hope
is
that
this
group,
this
work
group
that
we
developed,
is
able
to
take
everything
we're
talking
about
today
and
put
this
in
a
model
that
we
can
really
take
to
to.
You
know
to
the
world
and
help
others
understand
and
gravitate
to
this
complex
landscape
that
we
have
today
next
slide.
Please.
B
B
You
know
we're
technologists,
so
we
tend
to
focus
on
on
other
technologists,
how
how
we,
you
know,
see
our
journey,
but
you
know
we
wanted
to
think
about
the
c-suite,
the
vps,
the
the
program
sponsors
project
managers,
cross-trainers
people
who
maybe
you
know,
trying
to
pick
this
up
for
the
first
time
or
understand,
really
wrap
their
heads
around
it
and
maybe
they're
never
going
to
be.
You
know,
hands
on
the
keyboard,
but
they
really
need
to
think
in
a
cloud-native
way
right.
So
you
know
we
wanted
to
express
the
organizational
change
journey.
B
You
know
what
teams
need
to
be
created
or
grown
along.
The
way
do
you
need
to
outsource
some
of
your
skills
along
the
way
to
expand?
You
know
your
your
engineering
team
or
something
you
know
your
engineering
footprint
along
the
journey
will
probably
swell
and
then
start
to
contract.
As
you
know,
layers
of
abstraction
are
are
put
in
place
to
make
it
easier.
For
you
know
your
organization
to
be.
You
know,
cloud
truly
cloud
native
cloud.
B
First
right,
so
you
know
you
might
see
your
the
journey
go
from
a
cadre
of
experts
to
a
center
of
excellence
to
community
of
practice.
Right
we
have.
You
know:
we've
called
out
some
components
for
training
and
we've
also
had
a
heavy
focus.
There's
a
heavy
focus
on
the
open
source
software
community
right
not
only
to
consume
from
the
community,
but
also
to
you
know,
give
back
in
the
form
of
you
know.
B
Maybe
at
first
it's
engaging
in
forums,
asking
questions
you
know
proposing
issues
and
then
eventually,
as
you
build
your
you
know,
your
expertise
that
you
know
center
of
excellence,
etc.
You're,
you
may
even
be
giving
back
to
the
community
right,
either
through
through
tutorials,
on
medium
or
or
even
source
code,
that
you've
open
sourced.
F
F
We
wanted
to
focus
on
the
security
elements
so
for
process
here,
like
what
was
big
when
we
were
building
the
model
was
that
we
wanted
to
make
sure
security
was
everywhere
throughout
the
model
and
that
it
wasn't
its
standalone
thing
that
it
was
important
to
each
element.
So
we've
made
it
a
first
class
citizen
throughout
the
maturity
model,
but
also
we're
encouraging
people,
if
they're
using
the
model
to
do
that
so
to
embrace
that
you're
shifting
left
in
your
process,
you
you
know
in
in
the
level
one
you're
looking
at
security
straight
away.
F
How
are
you
building
it
into
everything,
you're
doing
and
then,
as
you
move
forward,
so
you
know
where
is
it
in
your
ci
process
in
level
two
at
level?
Three
like
what
is
automated?
What
continuous
scanning
can
you
have
in
place?
How
are
you
looking
for
misconfigurations
or
security
issues
as
part
of
that
level?
E
E
This
is
where
tools
like
oprah,
opa,
open
part
agency,
need
to
come
into
play
and
become
part
of
the
environment's
building
blocks,
whether
it's
not
to
allow
containers,
maybe
to
run
as
root
right
I'll.
Let
users
change
their
folder
to
the
folder
within
the
container.
These
policies
need
to
be
in
place
right.
We
cannot
continue
to
use
the
default
policies
any
longer,
with
ransomware
on
the
rise
and
other
current
attacks.
Pop
policies
are
more
and
more
important
than
ever.
E
C
D
D
Tls
is
certainly
going
to
be
part
of
a
production
infrastructure
and,
of
course,
authentication
and
authorization
are
going
to
be
a
really
important,
crucial
part
of
that,
and
that's
going
to
be
not
only
in
your
in
your
infrastructure
or
your
platforms.
Communities,
but
you'll
also
see
that
reflected
as
well
within
applications.
D
We
would
expect
to
see
that
there
at
level
three
we
would
again
really
see
that
you'd
be
taking
advantage
of
cncf
projects
such
as
zopa
and
caverno.
Again,
they've
already
been
touched
on
within
the
the
presentation
here,
but
we
can
see
how
we
can
reflect
how
critical
they
are
and
with
level
four.
We
expect
that
you
will
be
tuning
policies
within
production
and
we'd
also
think
that
you
might
be
considering
falco
and
other
tooling
for
additional
visibility
and
again
with
level
five
you'll
be
carrying
on
a
process
of
ongoing,
optimization
and
adjustment.
D
D
D
D
D
The
four
key
areas
of
people,
process
and
policy
and
technology
also
some
discussion
around
if
you
don't
fit
into
the
model
as
well.
If
you
think
well,
maybe
this
is
a
bit
prescriptive
and
how
we've
approached
that,
okay
and
when
the
when
the
right
time
might
be
to
consider
a
a
cloud
native
journey
for
you
and
again,
you
can
see
here.
We've
got
the
the
levels
laid
out.
D
We
also
went
into
further
detail
as
well
with
four
further
documents
as
well:
around
people
process,
policy
and
technology,
and
just
to
give
you
a
flavor
they're,
laid
out
with
an
introduction
again
key
categories
within
that
and
considerations
that
you
may
want
to
give
and
also
we've
incorporated,
as
you
can
see
within
people
and
just
the
the
category
of
security
there.
Now
we
have
that
for
all
four
of
the
of
the
four
key
areas.
D
D
This
is
a
very
much
edited
abridged
and
cleaned
up
version
of
our
original
source
material
and
it
outlines
again
the
the
four
key
areas
and
various
categories
organization,
change,
security,
auditing
logging,
ci,
cicd
change,
control
processes
and
and
within
the
technology
area
as
well.
We
can
see
application
and
release
operations
and
testing
and
issue
detection
and
policy
as
well.
D
D
Yep
so
yeah.
What
I'll
illustrate
now
actually
is
just
a
template
that
yeah
danielle
has
mentioned
now
as
part
of
a
call
for
action
for
us
for
the
the
cloud
native
community
and
we've
put
together
a
a
template,
and
it's
to
start
that
conversation
that
we
feel
is
so
vital
between
the
cartographers
working
group
and
all
the
tags
and
projects
within
the
cncf.
D
D
Where
do
I
focus
my
efforts
and
how
can
I
lay
the
best
foundation
now
to
adopt
those
projects
in
the
future,
and
so,
if
there
are
recommendations
and
thoughts
from
tag
security
on
where
projects
can
be
adopted,
where
they
made
fertile
considerations
that
we
can
start
to
build
into
our
our
written,
if
not
graphical
artifacts,
that
would
be
absolutely
fantastic.
We
would
really
value
that.
D
So,
just
as
a
simple
example,
we've
got
some
little
placeholders
here
we
may
see
falco
at
level.
Five
could
bring
it
into
level
four,
but,
of
course,
there's
a
real
conversation
there,
and
we
would
really
love
to
to
have
that
with
you
and
start
that
that
dialogue
moving
forward
so
so
just
to
quickly
refer
back
to
to
the
slides
here.
So
how
else
can
you
get
involved?
As
I
mentioned,
there's
the
the
spreadsheet
here
that
we
we
would
love.
D
D
A
C
I
have
tons
of
questions
too,
unfortunately,
unfortunately,
so
I
I
think
this
is
a
great
piece
of
work
event.
We
needed
something
like
this,
where
we
can
assess
you
know
different
enterprises
as
to
what
maturity
level
they
are
at
and
my
main
interest.
Personal
interest
comes
from
sas
providers
right.
There
are
small
time
sas
providers
who
use
cloud
native
technologies
underneath
that
and
we
have
no
visibility
as
to
how
mature
they
are
in
their
management
of
their
infrastructure
and
orchestration
and
all
the
security
controls
in
their
underlying
infrastructure.
A
Yeah,
actually
to
piggyback
off
of
that.
That's
a
great
example.
I
can
see
this
potentially
becoming
a
conformance
attestation
against
a
maturity
model
that
organizations
can
express
either
on
yeah
or
certification,
something
along
those
lines
that
they
can
express
publicly
to
their
customers
or
internal
to
their
employees
or
something
to
that
effect
to
be
able
to
show
like
their
level
of
maturity
and
adoption.
A
So,
first
off
I
see
a
lot
of
great
valuable
overlap
with
some
of
the
current
efforts
and
projects
that
this
group
is
either
sponsoring
or
partnering
on.
One
of
those
is
the
cloud
native
security
map
in
which
we're
looking
to
group
and
provide
more
of
a
global
view
of
that
trail
map
that
the
cncf
has,
but
from
a
security
perspective.
So
if
there
is
specific,
tooling
around
a
unique
space
within
the
cloud
native
security
map,
we
want
to
be
able
to
list
those.
A
Category
linking
that
in
with
the
cloud
native
security
map
that
way,
they
can
see
other
projects
that
are
in
that
realm,
that
can
provide
either
feature
parity
or
some
similarity,
or
at
least
the
value
at
that
maturity
level,
so
that
that's
kind
of
the
first
thing,
brandon
and
ash
are
are
kind
of
the
co-leads
for
that
or
they're
working
on
that
effort,
along
with
a
lot
of
other
folks
in
our
community
yeah.
Another.
F
I
have
a
question
on
that
for
you
so
the
way.
I
understand
that
just
to
make
sure
I
understand
this,
so
we'll
have
the
two
things,
but
we'll
have
interlinking
between
them
to
be
like
pointing
from
the
maturity
model
to
your
map
and
like
a
circular
motion,
if
you
will
is
that,
did
I
understand
that
correctly.
C
Can
I
quite
challenge
you
of
course
yeah?
So
since
you're
talking
about
the
maps
as
simon,
you
mentioned,
you'd
like
to
know
where
these
projects
fit
in
in
what
like
domains
like,
whereas
50
spirit,
whereas
oppa
fit
in,
I
think
you
can
leverage
that
from
the
map,
because
it
has
that
categorization
right
now
for
all
these
projects.
D
G
E
But
my
only
ask
for
that
is
I
want
to
question
some
things
when
I
talk
to
you
know
my
customers,
my
clients,
you
know
real
life
things.
You
know
out
there
in
the
fortune,
500
and
other
companies.
You
know
a
lot
of
them.
It's
about
patterns.
Everybody
wants
to
know
what
the
pattern
is
for
security
for
kubernetes
maturity,
those
kinds
of
things
and
then
the
the
tooling
that
the
spiffy
that
open
everything
else
comes
later
right.
So
first,
it's
that.
How
do
we
understand
what
the
patterns
are
to
actually
do
this?
E
The
right
way
right
on
a
scale
one
to
five
in
the
maternal
model
that
we
have
each
model
each
path?
There's
a
certain
pattern
to
achieve
that
level
of
maturity
right
and
there's
many
and
there's
many
opinionated
ways
prescribed
ways
we
can
do
the
tooling
for
those,
but
the
patterns
is
the
magic
of
what
we
did.
I
think,
within
this
majority
model
that
makes
sense,
and
then,
if
we
want
to,
you
know
actually
say
what
tools
to
use
to
prescribe
them.
G
G
So
I
can
see
that
that
this
particular
thing
fits
into
that
really
well,
and
it's
easy
for
me
to
take
this
and
say:
here's
a
here's,
a
set
of
things.
You
can
create
policy
around
that
that
helps
drive
standards
so
that
this
is
a
this
is
an
excellent
start
and
then
groups
like
spiffy
and
similar,
I
think,
would
be
more
like
a
template.
If
you
decide
to
use
spiffy,
here's
where
it
fits
in,
you
don't
have
to
use
it.
G
E
A
Those
controls,
as
well
as
the
supply
chain
security
paper
specifically
do
call
out
a
difference
in
assurance
levels
for
different
organizations,
in
that
a
low
assurance
organization
will
not
have
the
same
security
standard
level
as
a
high
assurance
organization,
meaning
they
can't
suffer
any
downtime.
They
have
extremely
rigorous
security
standards.
I'm
curious:
have
you
considered
in
the
maturity
model,
adjusting
some
of
those
maturity
levels,
given
that
different
organizations
have
different
assurance
needs.
F
So
we
we
started
out
by
saying
that
this
is
not
all-encompassing
or
all
you
know
prescriptive,
because
we're
like
we're
going
to
miss
stuff
along
the
way
so
and
we
tried
to
do
it
as
valuable
so
that
people
could
go
okay,
get
the
general
idea,
but
we
haven't
gone
to
the
level
of.
If
you
have
a
ton
of
regulations
or
if
you
you
know,
cannot
risk
downtime.
G
Yeah
and
that's
actually
a
really
good
point
to
also
make
to
to
state
that
it's
not
all
inclusive
like
in
terms
of
I'll,
give
you
a
really
example
where
we
cannot
really
play
100
effectively,
which
is
in
healthcare.
There's
something
called
high
trust
that
a
large
number
of
companies
have
to
adhere
to
in
order
to
operate
in
that
space
and
to
become
high
trust.
Certified
it's
run
by
a
private
sortium
that
private
consortium
requires
you
to
be
a
high
trust
organization
or
or
a
compliant
organization.
G
That's
aiming
to
become
one
that
has
very
strict
requirements
to
join,
and
only
when
you
join
can
you
gain
access
to
the
definitions
of
what
high
trust
is
and
what
the
baselines
and
benchmarks
are.
So
if
we
were
to
say
hey,
we
want
to
help
you
become
that
it's
like
we're
we're
out
of
the
picture
simply
because
we
can't
even
gain
access
to
the
to
the
materials.
G
G
C
Yeah
and
danielle
and
simon
to
frederick's
point.
I
would
like
to
add
that
you
don't
have
to
target
this
ultimate
vision
right
now.
You
can
do
it
in
phases.
You
know
csa
implemented.
Css
start
like
that
they
had
a
phase.
One
auditability,
you
know
score
that
they
provided
then
they
matured
from
there.
So
maybe
we
figure
out
what
the
road
map
to
this
vision
state
is
and
do
it
in
phases.
E
A
So
one
of
the
other
questions
that
I
had
was
whether
or
not
you're
limiting
some
of
the
recommendations
for
maturity.
Adoption
to
just
graduated
or
incubating
graduated
projects
to
either
encourage
organizations
to
adopt
incubating
projects
to
help
grow.
Some
of
that
community
help
them
reach
a
higher
level
of
maturity
or
in
the
case
of
graduated,
if
you're
at
a
higher
level
of
maturity,
you
really
should
be
using
graduated
projects,
because
you
have
that
established
need
for
functionality.
F
So
when
we
looked
at
it,
we,
the
four
of
us,
went
we're
not
going
to
be
able
to
cover
each
project
in
the
cncf
landscape.
So
we
took
the
viewpoint
that
we
would
just
incorporate
graduated
projects
at
this
time
and
that,
as
you
know,
they
graduate
or
incubate
more.
Why
not?
We
could
put
them
in
and
that's
really
where
we're
relying
on
the
tag
groups
to
help
us,
because
you
know
we
can't
be
experts
on
everything.
Unfortunately,.
E
Right
but
but
well,
I
can
be
just
kidding
about
the
patterns,
also
right,
so
whether
if
they
could
be
eating
it's
emerging
or
or
it's
fully
out
there,
I
mean
look
at
prometheus
right
when
that
was
in
sandbox.
It
was
still
a
great
tool
and
and
not
using
production
right.
So
you
think
for
what
it
is,
but
as
we're
doing
these
things,
though,
you
know
it's
about
the
pattern.
So
if
I'm
emerging
in
little
five
but
there's
something
that's
incubating
that
fits
into
that
that
pattern
one
I
say
you,
we
use
it
right.
E
That's
my
opinion
about
that.
So
there
are
many
main
things
that,
like
opa,
have
enterprise
like
like
styro
editions
right,
so
I
get
to
the
support.
So
maybe
the
other
question
is,
as
I
go
to
a
five,
so
I
want
to
be
looking
at
projects
that
also
has
enterprise
level
support
as
well
right,
so
there's
many
threads.
This
can
get
into
many
conversations,
but
I
think
it's
also,
you
know
not
to
be
prescriptive,
but
this
is
a
case-by-case
basis.
Also
right
so
one
show
does
not
fit
all
right.
D
Yeah,
sorry,
if
I
may
just
touch
on
one
small
detail,
we
we
didn't
impose
a
certainly
we
didn't
impose
a
hard
and
fast
rule
and
we
did
give
strong
consideration
also
to
incubating
projects.
We
know
that
incubating
project
many
incubating
projects
do
have
quite
a
significant
number
of
deployments
and
attract
a
lot
of
attention
even
before
they're
formally
graduated.
A
The
other
question
that
I
had
was-
and
I
have
not
looked
at
the
maturity
model
at
length
or
any
of
the
recommendations
within
it.
But
I'm
curious:
has
the
group
actually
looked
at
the
existing
documentation,
guidance
policies,
white
papers
that
are
either
generated
by
the
security
tag
or
any
other
sister
tag
groups.
F
A
E
E
I
think
we
built
this
on
our
own
experiences
of
best
in
class
solutions
for
for
our
clients,
and
this
is
what
this
is,
how
we
evolved
right
and
then
there's
many
different
levels
of
that
and
many
different
viewpoints,
and
you
know
opinions
if
you
will
on
other
ways
to
do
these
things
and
those
opinions
and
other
ways
doing
it
within
the
cncf
organization.
Obviously,
and
I
would
kind
of
urge
those
organizations
to
look
at
what
we,
what
we
did
and
sprinkle
in
their
opinions
into
it
as
well
and.
D
D
So
I'll
may
also
may
just
make
a
small
comment
as
well.
We
we've
put
together
this
work
so
far,
we're
really
keen
to
to
take
it
to
use
all
of
the
resources
that
you've
all
worked
so
hard
to
produce,
and
indeed
that's
part
of.
Why
we're
here
today,
so
that
we
can
start
that
conversation,
it's
probably
most
appropriate
if
we
work
with
the
recommendations
of
of
tag
security
on
what
you
would
like
us,
it's
helpful
for
us.
D
If
you
tell
us
what
you
would
like
us
to
review
and
we'll
by
all
means
work
through
that
it
would
be
difficult
if
we
simply
took
something
that
had
been
had
been
produced
and
then
said
this
is
without
discussing
it
with
you
first.
So
we
really
want
to
get
that
that
conversation
going
amongst
us
all.
So
hopefully
that.
A
Gives
you
some
background
as
well
yeah?
It
does,
and
I
think,
reaching
out
to
the
security
controls
working
group
aradna
is
the
stag
leadership
representative
for
that
group
to
talk
through
a
little
bit
more
of
that,
because
I
we
all
know
that
the
cloud
native
security
paper
is
over
40
pages
long
and
the
supply
chain
security
paper
is
almost
equally
as
long.
A
So
there's
a
lot
of
really
good,
rich
content
in
there
that
we're
trying
to
refine
and
provide
better
recommendations
through
our
new
revisions
coming
up
and
the
security
controls
group
is
breaking
that
content
down
into
a
little
bit
more
digestible
and
actionable
information
for
organizations
and
users,
customers
and
engineers
to
be
able
to
take
advantage
of.
I
would
highly
encourage
reaching
out
to
that
group.
G
We
one
quick
thing
on
the
security
controls
working
group
we're
discussing
about
changing
the
the
date
on
it.
So
if
you're
interested
in
participating
now
is
the
time
to
join
that
channel
and
join
in
on
the
discussion
there.
The
I
think
that
the
current
thing
proposal
is,
we
move
it
to
a
to
wednesday
in
in
the
afternoon.
D
G
D
E
Yeah,
some
of
us
will
be
attending
kubecon
live
next
week,
so
we're
going
to
actually
we'll
be
on
stage
presenting
this
as
well.
So
if
everybody's
call
is
a
cubecon,
definitely
reach
out
to
us
love
to
get
a
cup
of
coffee
with
you
and
with
the
team
and
further
discuss.
If
we
can
please
that'd,
be
amazing.
G
G
If
you
can
make
sure
that
the
information
is
on
the
note
so
that
we
can
so,
I
can
join
in
and
participate,
because
I
would
love
to
participate
in
some
of
the
things
that
were
listed
here
as
well.
There
they're
right
up
with
some
of
the
responsibilities
that
I
currently
have
in
my
in
my
job.
So
this
is
super
useful
thanks.