►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Inside the CNCF Project Security Reviews - Justin Cormack, Docker
Last year the CNCF started funding security reviews for its projects.
This talk examines the review process from the inside and looks at the outcomes and lessons from the reviews that have been performed so far. What vulnerabilities were found? What types of problem are common across projects? How should you prepare for a review? The talk will cover how to make the most of a security review, what to expect from it, what to bring to the review process, and how to maximise the benefits of a review. It will be illustrated with details of the review process for the Notary and TUF audits from the inside as I was involved in this process, and with a detailed analysis of the public reports, including Prometheus, CoreDNS, Envoy, Containerd and more. The talk will look at the issues found in the different projects, the areas in which issues were not found, and common themes.
https://sched.co/MPdf
A
So
as
I'm
based
in
Cambridge
as
a
pitcher
Cambridge
case,
anyone
doesn't
Cambridge
UK.
It's
a
small
tech
village
and
I
I'm.
The
security
lead
at
docker,
based
in
Cambridge
I'm,
a
contributor
to
the
CN
CF
s--
new
cig
security,
which
we'll
talk
about
today
and
I'm,
a
maintainer
of
the
notary
project,
which
is
a
secure
software
update
for
containers,
project
I'm,
just
in
comic
hi
everywhere
on
the
internet.
A
These
are
basically
not
penetration
tests,
but
they're
kind
of
detailed
outlines
of
what
the
security
relevant
parts
of
each
project,
each
ciencia
project
or
each
candidate
project
are
and
things
that
you
need
to
know
as
an
end
user
of
these
projects
about
them
from
a
security
point
of
view,
like
you
know,
do
the
do
the
goals
and
the
scope
of
the
project
makes
sense
from
a
security
point
of
view.
You
know.
Is
it
as
the
project
sanely
developed?
You
know,
you
know,
there's
good
standard.
A
Are
there
any
concerns
about
how
people
might
use
or
misuse
the
project
or
misunderstand
its
use,
or
anything
like
that
and
what's
the
kind
of
security
scope
of
a
project?
So
this
is
what
we're
trying
to
do
so
we're.
Basically,
we've
been
starting
with
some
security
focused
projects
and
then
we're
going
to
move
on
to
the
more
general
projects
where
security
is
an
aspect
of
what
they
do,
what
they
do
and
they
have
security
pieces,
but
they're,
not
specifically,
security
focused,
so
we're
working
on
in
toto
which
is
kinda,
wants
to
join
the
CNC.
A
F
is
not
a
member
project,
yet
an
open
policy
agent,
we're
working
on
at
the
moment
as
well.
Falco
is
kind
of
next
in
line
which
is
currently
sandbox.
Project
was
looking
to
switch
to
incubation
and
key
cloak,
which
is
a
proposed
sandbox
or
proposed
incubation
project,
I
believe
and
then
we'll
start
working
on
other
projects.
After
that,
please
feel
free
to
participate.
The
processes
are
all
open.
The
meetings
are
all
open
on
Wednesdays
and
there's
we're
on
this
soon,
as
you
have
a
slack
channel,
so
you
can
come
and
join
us
the
assessment
process.
A
A
A
A
When
we're
when
a
doctor,
when
we're
commissioning
audits
for
a
prodigious,
we
normally
would
spend
somewhere
between
50
to
150
thousand
euros
or
so
roughly
that
sort
of
order
of
magnitude.
Of
course,
depending
I
mean
it's
very
a
lot
in
size
and
scope
so
that
those
numbers
are
kind
of
bit
hand
wavy,
but
that's
the
kind
of
amount
of
money
they're
spending.
A
So
to
you
know
this
is
this
is
serious
cash
to
back
security
in
the
in
the
project,
which
is
great,
we've
actually
had
quite
a
lot
of
reviews
already
and
for
the
audit,
so
envoy,
Cardenas,
tougher
naturey,
together
prometheus
container
de
open
policy
agent
Nats,
the
communities
one
is
ongoing,
so
I'm
not
really
going
to
talk
about
it.
Much
it's
a
I
mean
Kunis
is
a
huge
project
and
this
has
taken
quite
a
lot
of
time.
A
So
it's
way
bigger
than
all
the
other
one,
and
so
it's
it's
it's
a
matter
of
months
rather
than
weeks,
and
it's
good
I
mean
the
results.
Gonna
be
really
interesting
when
they
come
out,
but
I,
hopefully
they'll
be
in
time
for
next
Q,
Khan
and
Falco
is
about
to
start
in
the
next
month
or
so
so
we'll
have
another
one
I
and
maybe
a
few
more
as
well.
They're
coming
up
coming,
all
of
them,
except
the
kubernetes
audit,
were
done
by
so
far
done
by
a
company
called
cure.
A
A
Each
other
than
all
it
takes
a
few
weeks
so,
like
maybe
three
or
four
weeks,
starting
with
a
detail
code
review
actually
looking.
You
know
looking
at
the
code
looking
for
potential
issues
and
then
black
box
penetration
testing,
based
on
things
that
you
reckon
might
be
an
issue
in
the
review,
because
it's
all
very
well
looking
at
the
code,
but
you
want
to
see.
Is
this
actually
exploitable?
You
know?
Is
it
really
seriously
exploitable
or
just
a
minor
issue
and
so
on?
A
You
know,
checking
protocol
error,
handling
lots
of
fuzz
testing
against
inputs
and
so
on,
and
also
looking
at
really
the
common
cases
for
the
kind
of
protocol
so
for
core
dns.
They
looked
at
all
the
common
DNS
issues
that
historically
dns
has
had.
You
know
because
there's
a
well-documented
set
of
things
that
dns
has
and
so
I
know
they
generally.
You
know
there
are
known
edge
cases
that
are
kind
of
common,
so
it's
always
good
to
look
for
those
I'm.
So
obviously
you
just
want
to
know.
Are
these
projects
secure?
A
You
know
this
is
the
important
thing:
it's
not
a
competition.
It's
not
a
kind
of.
You
know
that
the
overall
I
think
all
the
projects
did
pretty
well
there
weren't
any
horrendous
things,
and
actually
the
details
are
kind
of
more
interesting.
The
summary
and
anyway
I
will
give
you
a
summary
here's
a
kind
of
summary.
It's
not
terribly,
as
you
can
see,
don't
a
lot
of
issues.
A
Many
projects
had
very
very
few
I've
divided
them.
They
were
divided
into
vulnerabilities,
which
are
things
a
probably
exploitable,
especially
the
critical
ones
and
issues
which
are
things
that
you
might
use
to
ease
your
way
into
another
attack
later
and
should
probably
be
fixed,
but
they're
not
immediately
exploitable
directly.
A
Critical
is
obviously
something
that
you
can
actually
really
explore
it
in
a
potentially
serious
way,
whereas
layer
is
something
that
it's
not
clear,
why?
You
know
it's
not
clear
exactly
how
that
fit,
but
it
seems
to
be
exploitable
a
little
bit
so
they're.
Quite
a
variation,
we'll
talk
about
we'll
talk
about
wine.
That's
had
a
bunch
of
issues
in
the
in
a
minute.
A
I
talked
about
some
the
common
themes
as
well,
a
lot
of
the
projects
that
have
been
reviewed
or
written
in
go,
and
it
came
out
quite
a
lot
that
it's
hard
to
write
bad,
go
compared
to
things
languages
like
C
and
a
lot
of
the
time.
You
know
a
lot
of
the
go
code.
Just
avoids
a
bunch
of
the
issues
that
historically
penetration
testing
would
have
found
in
in
C
code.
A
lot
of
pen
testing
companies
do
a
lot
of
work
with
C
because
historically
that's
been
where
there's
well.
A
It's
still
in
the
present
its
where
there's
been
a
lot
of
issues
and
just
changing
the
language
makes
a
huge
difference
so
far,
yeah
the
majority
of
products
wouldn't
go
there.
Obviously
other
languages
used
in
CNCs
now
as
well.
There's
some
Brust
code
now
and
things
like
that.
But
there's
haven't
been.
Oh
then
we
had
the
C
and
C++
pieces,
so
envoys
are
in
in
C++
and
Nats
had
a
client
written
in
C,
which
caused
a
lot
of
the
issues.
We
talked
about
in
more
detail.
A
These
things
can
be
mitigated
and
there's
also
a
bunch
of
issues
around
scope
that
we'll
talk
about.
So
let's
look
at
core
DNS.
First,
the
most
kind
of
exciting
aka,
critical
vulnerability
and
core
DNS
was
around
caching.
So
Cortinas
has
a
caching
plug-in
and
basically
it
you
can
do
a
DNS,
lookup
and
it'll
it'll.
Look
up
on
the
authority
of
DNS
server.
It'll
come
back
and
it'll
store
the
results.
A
It
doesn't
have
to
go
back
and
stuff
it
I
could
go
back
to
the
server
later,
but
it
was
probably
mostly
with
this
that
was
kind
of
interesting
in
that
it
didn't
check
that
the
when
they
asked
you
know,
say
you
were
asking
the
DNS
server
for
a
look
out
for
WWE
Google
comm.
The
caching
plugin
didn't
actually
check
whether
the
DNS
result
that
actually
came
back
from
the
Google's
DNS
server
was
actually
for
WWE
google.com.
It
could
have
been
for
another
address.
You
think.
A
Well,
that's
not
very
likely,
but
if
you
can
say
what
it
meant
is
that
if
you
could
make
the
code
to
a
lookout
for
a
DNS
server,
you
controlled,
you
could
send
back
a
bad
result
that
gave
that
pointed
WWE,
Google,
comma.
Your
infrastructure
say,
which
would
be
a
very
significant
issue,
so
the
moral
of
this
is
always
always
validate
user
input.
Even
if
it
seems
bizarre
that
you
know
Google's
name
servers
going
to
come
back
with
Google's
DNS,
but
I
mean
it's
like
not
it's
not
necessarily
the
case,
so
validation
is
incredibly
important.
A
We
see
a
few
more
validation
issues
with
other
things
later.
Never
trust
input
big
takeaways
from
this.
You
know
it's
a
very
well-written
project,
users
re.
They
don't
actually
implement
their
own
DNS,
where
they
use
them,
go
DNS
library,
that's
really
really
well-written
and
supports
a
lot
of
a
lot
of
the
DNS
protocol
really
really
well.
There's.
A
Actually
more
was
one
of
the
recommendations
actually
there's
more
features
in
the
DNS
library
that
they
could
actually
support
around
around
security
features
around
doing
a
second
things
like
that
which
they
could
add,
but
you
know
they
found
it
hard
to
find
issues
which
is
great.
That's
what
you
want
is
if
it's
difficult
to
run
issues.
They
recommend,
though,
carrying
on
doing
security,
races
auditing
to
find
things
like
the
caching
issue
during
development,
rather
than
kind
of
at
the
end.
So
you
know
think
about
security.
A
All
the
way
along
as
you're
developing
container,
they
didn't
have
any
vulnerabilities.
They
had
one
issue,
it
was
kind
of
it's
a
really.
It's
a
slightly
weird
issue:
it's
just
around
the
config
file
and
it's
really
hard
to
see
how
it
could
be
exploited
basically-
and
we
use
it
to
create
directories
under
different
user
IDs,
but
you're
normally
running
it
as
root.
A
So
it's
kind
of
not
clear
how
significant
it
is
so
kind
of,
but
they
kind
of
think
you
know
they
found
something,
but
the
biggest
takeaway
I
think
where
the
container
Lee
was
that
it
was
not
clear
what
the
security
escape
really
was.
Content
is
really
weird
position
in
the
stack.
Is
it
sort
of
sits
in
between
dr.
Koon?
A
A
A
But
you
it's
got,
you
know,
tend
to
have
a
lot
of
issues
and
it's
not
clear
we're
really
whether
it's
good
ideas
to
do
to
have
done
that
at
all.
You
know,
even
for
a
small
small
C
implementation
of
a
straightforward,
simple
protocol
with
small
attack
service.
They
found
critical
issues
and
less
severe
issues.
So
it's
really
really
problematic.
Writing
C!
You
have
to
be
very,
very
careful
if
you
want
to
have
a
secure
C
project,
that's
safe
for
public
consumption
and
it's
not
impossible,
but
it's
a
lot
of
and
it's
it's.
A
You
know
it's
not
like
the
people
who
were
doing
this
were
inexperienced,
see,
programs
or
anything.
You
know
it's,
it's
just
really
really
hard
I
mean
I
was
a
C
programmer
for
many
years,
and
it's
a
horrible
language
to
do
things
like
parsing
and
things
in
string,
manipulation
and
things.
It's
just.
It's
really
really
not
very
nice
at
all.
A
There
were
good
reasons
for
having
seeker
because
of
bindings
I.
Think
recently,
rust
has
become
a
serious
contender
for
writing
C
bindings
and
it's
definitely
worth
considering
if
you're
doing
something
where
it's
the
aim
is
to
implement
the
C
API,
so
you
can
implement
it
with
other
things
or
consider
writing
native
bindings
for
lots
of
languages.
I
know
it's
a
lot
of
work,
but
you
write
a
Python
binding,
a
ruby,
binding
and
node
behind
it.
A
Whatever
it's
like
it's
work,
but
it
could
be
less
work
than
writing
it
and
see
because
the
amount
of
time
you're
gonna
have
to
spend
writing
good
C
code
is
really
really
hard,
so
think
about
it.
How
much
works
involved
safety
first
use
tooling,
fuzz
testing,
as
fuzz
testing
is
good
for
things
like
this
use,
static
and
dynamic
analysis.
Tooling,
there's
a
there
is
a
lot
of
tooling
for
C,
because
it's
been
a
problem
for
so
long.
A
So
that's
good
portability
is
further
problems
there,
because
if
you're
writing,
Windows
and
Mac
and
Linux
clients,
for
example,
for
things,
that's
actually
three
different
environments,
you
need
to
test
and
they
actually
have
different
you're,
probably
using
different
libraries
for
a
lot
of
stuff.
So
that's
a
bigger
you're,
effectively.
Writing
in
three
versions
of
it
anyway,
parsing
in
C
as
a
nightmare,
really
trying
to
avoid
that
if
you
can
and
Ord
it
envoy
is
kind
of
interesting,
because
it's
written
in
C++
not
say
and
Super
Plus
is
a
much
better
language.
A
From
that
point
of
view,
the
biggest
takeaway
actually
from
that
from
the
issues
was
actually
an
issue
that
you
see
every
now
and
again,
the
admin
interface
wasn't
secure
and
it
was
kind
of
not
very
well
designed.
They
had
been
interests.
It
would
accept
commands
from
get
requests,
so
you
could
shut
down.
You
could
shut
down
an
envoy
with
a
get
request
on
the
admin
interface,
which
is
kind
of
nasty
admin.
A
Interface
is
a
really
weird
thing
because,
like
episo--,
we
must
have
a
nice
GUI
for
the
house,
you
know,
and
then
someone
puts
something
together
in
a
hurry
and
doesn't
really
think
about
it.
I
think
it's
better
to
not
do
an
admin
interface
just
because
you
want
it
to
look
nice
in
a
demo
either
make
a
production
quality
one
or
don't
do
it
at
all,
and
you
just
see
a
lot
and
like
the
halfway
house
of
its
kind
of
there.
But
it's
not
really.
A
And
most
people
are
actually
going
to
end
up.
You
know
configuring
it
through
config
files,
command
line,
that
kind
of
thing
and
not
through
the
admin
interface
anyway.
So
is
it
worth
having
not
sure
C++?
Does
it
suffer
the
same
problems
as
C?
The
answer
is
a
little
bit
potentially,
but
if
you
use
it
in
a
more
sort
of
see
like
way,
the
more
you
use
C++
as
modern
as
the
kind
of
modern
C++,
the
less
you
have
problems.
A
You
know
it
has
automatic
memory,
management
and
things
if
you
just
properly,
but
you
can
use
it
in
otherwise
and
in
that
the
issues
that
were
found
were
kind
of
that
sort
of
thing.
There
was
an
in
32
overflow,
always
overflows
a
bit
of
pain
and
C.
Sometimes,
if
be
careful
and
they
use
after
free
which,
again,
if
users
making
memory
management,
it's
not
gonna
happen,
but
the
team
were
really
good
at
actually
using
tooling
to
help
find
these
issues
and
they
actually
overall
look
a
basis.
A
You
know
it
was
pretty
good
as
it's
a
large
it's
a
much
larger
codebase
than
sort
of
Nats
C
client
by
orders
of
magnitude,
and
it
had
you
know
not
very
many
issues
considering
so
overall
yeah
C++
is
fine.
Don't
worry
about
using
that
toughened
nature.
Iwere
was
it
together,
they
kind
of
not
really
terribly
much
to
say.
Both
projects
had
previously
had
security
audits
actually
buy
one
at
least
one
of
them
by
the
same
company
and.
A
Not
massively
large
numbers
of
things
had
changed
since
the
previous,
or
so
it
wasn't
hugely
like
you
know,
they've
dug
into
some
of
the
issues
that
come
up
before
and
things
like
that.
Again,
there
was
a
small
input,
validation
issue,
that
input
validation
is
really
really
important
and
it's
but
yeah.
It
was
kind
of
a
kind
of
not
that
one
that
interesting
open
policy
agent,
the
again
cross-site
scripting
issues
on
on
the
query,
interface
again
anytime,
you
do
anything
with
sort
of
you
know:
REST
API,
HTML
ap,
on
HTTP
API.
A
You
need
to
be
careful
about
uncensored
input,
cross-site,
scripting,
CSRF,
all
those
things
there's
a
you
know,
checklist
of
things
just
go
through
it
Spain
his
work,
but
it's
understood
I
just
you
know,
never,
never
trust
to
use
an
input
and
make
sure
that
you,
actually
you
know,
work
out.
You
know
parse
it
carefully
work
out
if
you're
displaying
what
is
untrusted
input,
make
sure
you've,
sanitized
it
and
so
on.
Based
on
where
you
I
mean
it's,
it's
tedious
and
durable
and
the
other
issue
with
a
vapor
that
was
kind
of
an
annoying.
A
It
was
kind
of
put
down
as
a
documentation
issue,
but
I
think
in
the
way,
it's
actually
more
of
a
conflict,
language
design,
issue
a
lot
of
people,
don't
really
think
much
about
the
configuration
language
and
definitions
of
their
code
because
it
tends
to
as
you're
when
you
start
a
new
project.
You
suddenly
rise.
A
You
need
a
config
file
because
you
you
have
to
stop
hard
coding,
the
things
you
do
when
you
write
the
first
five
lines
of
code,
so
the
problem
we
hear
was
that
you
can
put
an
authentication
taken
in
the
config
in
order
to
for
access
control,
but
just
putting
an
authentication
taken
in
the
config
doesn't
enable
authentication
authorization
in
the
in
the
confer.
You
actually
have
to
also
turn
it
on
explicitly,
which
is
unexpected,
to
say
the
least.
A
Prometheus
now
Prometheus
is
a
really
interesting
one.
Okay,
we've
talked
about
scoping
out
what
what's
in
and
what's
out
and
what
your
projects
trying
to
do
and
what
it's
trying
not
to
do,
and
the
entire
audit
basically
ended
up
being
extreme
disagreement
about
scope
and
all
the
issues
said.
No.
This
was
flagged
as
a
false
alert
and
expected
behavior
by
the
from
atheist
team
and-
and
there
was
a
lot
of
longer
comment
really
that
they
decided.
A
The
Prometheus
team
had
decided
that
security
and
how
you
secure
your
prometheus
endpoints
was
out
of
scape
and
it's
the
users
problem
to
scare
Prometheus
endpoints,
whereas
the
audit
team
decided
that
that
would
that
was
never
would
possibly
make
a
bit
of
software
in
the
modern
age
that
didn't
really
think
about
securing
endpoints,
and
so,
in
the
end,
the
only
outcome
of
this
was
a
dock
in
documentation,
PR,
which
basically
added
some
documentation.
Saying
security
is
your
problem.
A
Now
it's
a
it's
a
kind
of
complex
issue
this,
because
in
many
ways
it's
kind
of
reasonable.
You
want
projects
to
be
able
to
spend
time
working
on
the
important
things
that
matters
are
them
like
making.
You
know
making
the
things
that
makes
Prometheus
really
valuable,
really
valuable.
You
know
making
you
know,
making
logging
incredibly
successful.
I
mean
Prometheus
has
been
extremely
valuable
for
everyone,
I
think
and-
and
no
one
disagrees
about
that.
A
But
the
complicated
thing
about
prometheus
is:
there
is
normally
a
sort
of
separate
API,
with
very
different
permissions
to
the
rest
of
your
API
I
pick
it's
being
read
by
a
different
process:
it's
not
the
it's
not
actually
usually
the
same
thing.
That's
calling
your
API
to
actually
do
API
operations.
It's
usually
a
completely
separate
process.
Ting,
you
know
scraping
the
Prometheus
endpoint,
and
so
it's
kind
of
it
will
there's
actually
reasonable
arguments
for
having
a
sort
of
narrow.
A
You
know
at
least
a
default
kind
of
wherever
easily
setting
up
authentication
to,
though,
because
you've
got
it
on
Prometheus
endpoint,
on
every
single
API
endpoint
on
every
machine
you've
got
on
every
service.
You've
got
it's
a
lot
of
endpoints
to
have
to
write,
you
know,
have
to
set
up
proxies
or
whatever
other
way
of
authenticating,
and
maybe
they
could
do
something
useful
I
think.
A
But
my
main
kind
of
concern
is:
is
the
audit
should
have
gone
ahead
without
having
decided
on
this
gate
before,
because
it's
effectively
it
was
a
total
waste
of
money
because,
like
they
looked
at
some
stuff,
they
disagreed
and
we
got.
You
know
a
dog's
PR
that
you
know
really
didn't
justify.
The
amount
of
effort
spent.
So
I
think
that,
as
part
of
why
we
want
to
do
security
assessments
and
then
in
the
security
is
that
we
can
help
iron
out
these
issues
before
we
go
through
all
this
and
and
really
understand.
A
A
As
I
said
the
there's
more
audit
going
on
now-
and
you
know
starting
now
so
there's
this
process
would
be
ongoing
and
hopefully
we'll
get
all
the
projects
in
the
CNC
F
down
and
also
lots
of
candidate
projects
that
want
to
join
the
CNC
F
and
projects
they
want
to
move
on
to
a
new
stage
and
if
you're
interested
in
all
in
the
whole
process
come
along
too.
You
know
come
along
to
security,
although
all
of
this
is
happening.
All
that
assessment
stuff
happens
in
public.
A
The
audits
happen
in
private
with
the
team,
because
obviously
they
may
find
significant
serious
issues
that
need
fixing.
So
we
can't
they
can't
the
process
can't
be
public,
but
the
way
the
process
works.
Is
you
know
that
the
steams
tied
up
slack,
channel
or
email,
and
they
talk
to
the
auditors
and
suggest
things
that
they
want
to
audit
and
things
that
might
be
at
risk
and
discuss?
A
You
know
bounce
forward
things
that
they
found
and
things
as
it
happens,
and
then
but
then
the
final
reports
is
published
after
the
issues
have
been
fixed,
but
with
the
assessments
because
we're
not
doing
pen
testing,
we
have
fully
not
finding
massively
important
issues
ever
we
can
do
the
whole
process
in
public.
So
if
you're
interested
in
how
this
stuff
works
and
and
or
interested
in
the
particular
projects,
then
please
come
along
and
join
in
and
participate
and
think
about.
You
know
think
about
your
threat
models
and
so
on.
A
First
and
really
try
and
document
everything-
and
you
know,
there's
a
bunch
of
tips
for
strengthening
your
code
here.
You
know,
don't
trust
your
inputs.
We
can't
think
about,
say,
use
tooling
to
help
you
spend
the
time
on
the
deep
dive
on
security
parts.
Reviewing
is
incredibly
important
code
review.
Think
about
you,
know
security
as
part
of
your
code
review
process.
A
If
you're,
if
you
want
and
someone
to
help
you
with
code
review
on
security,
critical
parts
like
say,
you're,
doing
part
of
your
code
that
maybe
you're
using
cryptography
or
something
and
you're
not
sure
if
you're
doing
it
right
come
and
talk
to
security,
if
we
can
find
some,
what
we
can
pull
someone
out
who's
got
expertise
in
that
area
as
a
there's,
a
really
big
pool
of
people
who
participate
in
security.
So
we
can
come,
and
you
know,
help
you.
A
If
you
want
to
know
how
should
you
building
something
right
and
keep
the
list
in
the
back
of
you
know
the
parts
that
you
worry
about.
It's
really
helpful
to
like
have
a
sort
of
paranoia
list
of
things
that
you
think
like
hey,
I
write
this
K,
but
I.
Don't
know
if
I
really
did
it
right,
you
know,
or
maybe
something
could
happen
and
when
we're
doing
the
nature
in
tough
audits,
I
kind
of
I
passed
my
list
to
the
auditors
and
they
looked
through
it
and
they
didn't
find
any
issues
with
the
bits.
A
I
was
paranoid
about
which
was
reassuring,
because
I
knew
that
they'd
spent
some
time.
Digging
into
them
and
I
was
you
know,
so
my
paranoia
in
that
case
was
not
particularly
justified,
but
you
know
you're
paranoid
can
be
justified.
You
can
there's,
you
know,
there's
lots
of
things
where
you
think.
Maybe
there's
something
weird
about
this.
Maybe
there's
something
there
because
you
haven't
thought
off
as
well,
but
it's
always
good
to
have
a
starling
points
to
dig
into
you
know.
A
Audit
can't
cover
everything
you
know
it
would
take
months
and
months
and
months
to
go
through
every
line
of
code
and
every
interface
and
especially
with
really
big
project.
So
I'm,
you
know,
having
some
focus
is
really
important.
An
external
review
is
a
really
valuable
part
for
security
journey,
and
it's
not
often
I
mean
lot
of
this
has
happened
in
behind
closed
doors,
for
you
know,
closed
source
projects
and
things
like
that
in
the
past.
A
A
So
yeah,
so
the
question
is:
do
we
have
a
common
view
of
how
much
we
trust
each
component?
Because
of
you
know
based
on
the
others,
we
got
Mike
here,
yes,
yeah.
We
don't
at
the
moment
and
I
think
that's
something
that
again,
we've
talked
about
with
security,
about
putting
together
over
time
it's
it's
kind
of
difficult,
because
the
components
do
such
different
things.
A
Yeah
that
you
know
the
difference
between
you
know
different
parts
of
the
stack
we're
actually
we're
putting
together
as
a
sort
of
a
a
kind
of
security
landscape
of
projects
and
we're
trying
to
work
out
at
the
moment.
It's
sort
of
classification
for
the
kind
of
things
that
things
are
like
are
they
you
know
they
probably
from
the
security
point
of
view.
They
part
the
data
panel
control
play.
You
know
you
know
what
what
when
are
they
used?
Are
they
used
at
build
time
or
production
time?
A
You
know
so
that
we
can
try
and
group
things
into
areas
where
they
have
similar
or
related
things.
There's
obviously
there's
a
bunch
of
products
that
the
input
snap
is
flow
through
each
other,
like
the
container
the
case
with
community
to
contain
a
data
run,
see,
and
things
like
that,
so
there's
a
kind
of
there
are
definitely
clusters
and
related
things
and
flows
and
and
and
projects
that
have
overlaps
or
projects
that
are
alternatives
that
do
the
same.
You
know
that
feel
the
same
rather
than
the
stack
and
should
be
evaluated
in
the
same
way.
A
A
A
A
But
it
doesn't
address
some
of
the
things
like
why.
Why
do
we
have
to
configure
it?
Why
are
those
options
there
at
all
and
those
kinds
of
things
which
I
think
is
also
really
important
in
actually
hardening
things
by
by
making
the
configuration
better
and
I
think
that
is
really
something
that's
important,
but
yeah
we
definitely,
and
we,
if
you
want
to,
if
you
want
things
from
six
security,
please
come
and
open
an
issue
on
our
github
repo
and
we
will
try
and.
C
Hi,
are
there
any
plans
for
six
security
to
look
at
kubernetes
distributions
so
in
the
way
that
you
get
like
a
conform
and
kubernetes
distribution,
his
own
privacy,
like
six
security,
has
looked
at
this
and
said
yeah
out
of
the
box.
It's
not
horrible,
because
that's
somewhere,
I
think
customers
having
quite
a
bit
of
confusion.
You
know
the
different
distributions
and
there
are
other
different
settings.
I.
A
D
C
A
I
mean
I,
think
some
of
its
I
mean,
if
you
some
of
it
is
that
is
arguably
the
distributions
responsibility,
but
if
they
want
to
work
on
common
tooling,
for
example,
to
help
that
would
be
really
variable
so
yeah
there's
it
would
definitely
you
know
it.
It
would
be
nicer
than
the
distribution
started
working
with
us
to
work
on
things
like
that.
D
A
I
think
I
mean
run
see.
The
OCI
is,
is
sort
of
a
sibling
organization
of
CN
CF,
so
I
think
we
can
probably
we
should
definitely
consider
it
in
scape
I
think
because
it's
it's
a
sort
of
historical
anomaly
that
run
see
is
a
OCI
project,
not
a
CN
CF
project
and
it's
the
only
non
it's
a
kind
of
non
spec
part
of
the
ACI,
and
it
would
make
I
mean
I.
It
would
make
more
sense
if
it
front
C
was
in
sense.
A
Yes,
so
yeah
I
think
I
think
you
could
definitely
be
considered
in
the
scape,
and
it's
definitely
part
of
the
kubernetes
security
story
is
the
bet
that
is
run
C,
because
it's
running
well
run
C
or
an
equivalent
piece,
and
you
can't
really
consider
community
security
without
or
container
to
use
security
of
that
matter.
Without
really
considering
the
run,
see
the
actual
runtime
piece
as
well
so
yeah
I
think
it
would
definitely
be
weird
to
exclude
it.
E
And
with
the
pen
test
being
very
much
point
to
time,
is
there
any
consideration
given
to
like
a
like
a
camera
and
like
a
program
for
community
sub,
finding
bugs
and
a
bug
bounty
program,
and
would
that
be
something
that
the
individual
projects
would
have
to
look
after
or
would
it
be
at
the
CN
CF
level?
There's.
A
It's
still
there's
there's
a
proposal
with
the
lowness
Foundation
and
Netflix,
and
a
few
other
people
that
there
was
a
talk
about
it.
Dokic
on
in
the
security
tag
there
that
we
were
there
were
that
Netflix
analyst
Foundation
are
interested
in
supporting
a
bug.
Bounty
for
container
escape,
obviously
container
escape
is
a
pretty
like
it's
one
kind
of
narrow
thing,
but
it's
also
one
incredibly
important
thing
in
covers
the
learners
kernel
and
things
like
that.
So
it's
why
the
events
foundation
core
is
kind
of
involved,
as
well
as
just
CN
CF.
A
So
the
the
plan
is
to
try
and
implement
that
this
year,
there's
actually
there's
a
bunch
of
worried
if
you
that
there's
a
very
short
talk
which
is
in
this
security
video
from
docker
comb,
which
you
just
definitely
watch
from
net
from
the
michael
at
netflix.
So
that's
happening
and
I
think
that
hopefully
can
set
a
precedent
for
bug
bounties
for
other
parts
of
the
stack,
potentially
I.
Don't
think
it's
something
that
is
being
worked
out.
Yeah,
buddy
I
think
it's.
A
A
It
is,
but
some
of
the
other
ciencia
projects
like
young
and
not
have
never
had
a
CVE
yet
and
there's
like
they're
just
going
down
in
the
beginning
of
this
road
and
I
think
they
need
they
probably
need
help
on
that
function
before
they
get
bug
bounties
on
their
code.
So
you
know,
there's
a
sort
of
maturity,
level
thing
around
polk
counties
as
well,
but
but
it's
definitely
yeah.
It's
definitely
something
that's
at
least
happening
for
part
of
the
space.
F
So
the
or
so
I
had
a
question
about
that:
helped
a
little
bit
with
the
high
over
here
hi
Jason,
so
I
had
a
question
about
new
projects.
One
of
the
things
that
key
r53
had
put
out
for
one
of
the
projects
was
the
suggestion
for
ongoing
security
audits
for
these
projects.
I
was
curious
to
hear
from
perhaps
other
projects
or
what
other
people
are
doing
for
these
ongoing
security
audits.
F
Like
is
that
part
of
the
PR
process,
you
that
something
that's
being
done
like
security
scanning
through
external
vendor
tools,
or
is
this
some
other
process
that
when
people
are
going
down,
the
security
audit
trail
like
what
can
they
do
to
make
their
systems
more
secure
and
going
through
that
process?
Yeah.