►
From YouTube: A Raccoon And a Group Of Turtles Secure Clusters Together! - Pushkar Joglekar & Naadir Jeewa, VMware
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A Raccoon And a Group Of Turtles Secure Clusters Together! - Pushkar Joglekar & Naadir Jeewa, VMware
How does a Raccoon and a bunch of Turtles find common ground? Answer: You find a Goose who makes space where both feel welcome. In this session, Pushkar Joglekar and Naadir Jeewa will talk about how a multi-year collaboration where Kubernetes SIG Cluster Lifecycle, SIG Security & TAG Security came together to write the first community driven self-assessment of a Kubernetes sub-project: Cluster API. The session will cover how it all started from the basics with data flow diagrams to understand the internals of the project, then using that to model threats and assess next steps. Next, they will discuss challenges faced doing this exercise with folks around the globe (5 countries), limited maintainer time, doing our best to avoid zoom fatigue while trying and at times failing to be async first. Finally they will talk about what is happening with the findings from this exercise and how they plan to apply the lessons learnt from this exercise to future self-assessments across all Kubernetes sub-projects. Come for the stories from the animal kingdom; Stay for the real stories of humans bringing their best self to break some new ground in the form of community driven security improvements!
B
A
Yeah-
and
we
are
here
to
talk
about
how
some
animals
like
to
ride
some
bikes-
well,
not
really,
but
I've,
gotten
a
lot
of
questions
about
the
title
and
people
are
like
what's
up
with
the
animals,
so
they
are
actually
talking
about
three
projects.
Each
Project's
logo
happens
to
be
an
animal
officially
or
an
officially.
So
the
first
group
that
we
actually
work
with
is
cncf
tax
security,
I'm,
a
tech
lead
for
that
that
tag.
You
might
have
seen
some
of
my
friends
in
the
keynote
stage
in
the
morning.
A
B
Go
yeah,
so
there
is
a
few
friends
of
Terry
Pratchett
this
quilt.
The
Discworld
is
a
big
world
big
flat
weld
on
the
back
of
a
turtle.
Terry
Pratchett
was
famously
asked.
What's
underneath
the
turtle
and
he
replant
wise
somebody
said
it's
Turtles
all
the
way
down.
So,
given
that
kubernetes
cluster
apis
using
kubernetes
to
build
kubernetes
clusters,
we
thought
well
what's
underneath
that.
Well,
it's
also
kubernetes
all
the
way
down.
Hence
the
turtles
yeah.
B
So
how
do
we
get
started
so
back
in
2019,
I
was
I
sort
of
I
was
sort
of
in
a
field
engineer,
more
sort,
more
customer
facing
role,
but
I
was
a
user
of
cluster
API
I
was
worked
on
the
cluster
API
project,
I
sort
of
know,
I'm,
a
sort
of
nosy
person,
so
I
like
to
spy
on
the
CNC,
ftoc
and
I
noticed
they
were
doing
security
assessments.
Various
projects
I
was
like.
Could
we
could
we
get
one?
B
Please
can
I
and
not
much
happened,
and
the
reason
for
that
is
wasn't
really
plugged
into
plugged
into
the
cncf
that
well
I
didn't
really
know
that
many
people,
so
you
kind
of
just
stayed
there
for
a
while
and
that's
because,
like
you
know,
I'm
not
chopping
wood
carrying
water,
as
we
mentioned
in
keynote
I'm,
not
active
in
that
space.
I
didn't
really
have
the
time
for
it
at
the
time,
so
we
just
kind
of
just
let
it
slide
and
let
other
things
happen
and
then
April
2021
Matt
busko.
B
Finally,
we
got
an
issue
open.
Maybe
let's
do
one
around
a
kubernetes
sub
project.
So
if
those
who
aren't
familiar
kubernetes,
there's
a
overall
kubernetes
project,
big
code
base,
there's
lots
of
little
sub
projects
for
various
things.
Underneath
there
organized
through
special
interest
groups
plus
the
API
is
part
of
said,
plus
life
cycle,
and
we
finally
got
a
chance
to
do
security.
A
B
A
And
with
security
audits,
one
of
the
things
was:
do
we
want
to
increase
the
scope
or
limit
the
scope?
So
I'll
talk
more
about
that.
The
other
thing
another
also,
as
you
can
guess
from
his
accent,
is
not
from
San
Francisco
Bay
area
and
I'm
from
San
Francisco,
Bay
Area.
Most
of
our
tag
was
based
in
North
America,
so
we
really
had
a
problem
about
like.
If
we
had
to
do
an
in-sync
meetings
and
discussions,
he
would
have
to
sacrifice
his
evening
time
with
family,
which
wasn't
great
me
being
in
North.
A
B
So
Fabrics
is
one
of
the
maintenance
class
API
project.
Luba
may
even
know
if
it's
one's
Cube,
IDM
Cube
IDM,
is
the
sort
of
heavily
used
by
cluster
API.
It
has
kind
of
already
been
through
security
audit
through
the
main
kubernetes
project,
but
because
it's
a
core
dependency
and
we
use
it
in
interesting
ways.
We
we
really
wanted
some
subject
matter,
expertise
from
leaving
it
and
we
also
had
Ankita,
who
was
my
sort
of
co-conspirator
on
the
cluster
API
side.
His
was
based
in
Bangalore.
A
Yeah,
so
we
had
a
group
of
people,
we
had
a
project
or
a
idea,
but
we
had
to
get
started
somewhere.
So
we
as
with
everything
on
cncf,
it
started
with
a
GitHub
issue
and
the
idea
was
in
cncf
tax
security.
We
do
self-assessments
for
security
for
any
graduated
project
of
cncf.
So
for
folks
who
are
not
familiar,
cncf
is
the
big
umbrella
under
which
kubernetes
and
all
other
graduated
projects
are
and
then
in
the
same
graduated
projects.
A
There
are
multiple
sub
projects,
so
the
sub
project
that
nadir
was
maintaining
at
the
time
was
called
cluster
API
and
it
was
under
kubernetes
and
tag
Works
in
this
umbrella.
So
there
was
a
gap
here
and
what,
when
I
went
to
tax
security,
they
were
like
well,
it
seems
like
a
good
idea,
but
we
really
haven't
done
it
and
I
know.
We
have
some
friends
in
kubernetes
community
who
do
great
work
in
security.
A
They
are
called
sick
security
and
I
said
yes,
I
know,
because
I
am
part
of
them,
so,
luckily
being
in
the
right
place
at
the
right
time,
I
could
then
go
to
the
next
security
meeting
and
share
with
them.
You
know
I
heard
from
cncf
tax
security.
They
do
something
like
a
self-assessment.
We
don't
have
a
process
like
that
for
a
sub
project
like
cluster
API
in
kubernetes,
we
being
in
the
same
slack
space
like
cluster
API,
folks
being
in
the
same
Google,
Groups
being
in
the
same
GitHub
org.
A
Maybe
it
makes
sense
to
adopt
what
the
cncf
tax
security
did
and
use
it
in
seek
security.
So,
as
you
see
and
expect
from
Community
everybody
welcome
that
idea,
including
the
chairs
they
were
like.
Yes,
let's
do
it,
and
that
was
a
great
thing
for
me
as
a
newish
contributor
and
then
I
could
go
to
another
and
say
well.
We
have
a
solution
now,
so
we
created
this
GitHub
issue
in
tax
security
to
keep
a
track
of
where
we
are,
but
the
real
work
actually
started
in
kubernetes
security.
A
So
in
all
the
screenshots,
please
note
the
org
name
and
the
repo.
Wherever
you
see
it-
and
here
is
where
we
actually
started
discussing
things
and
first
thing
was:
all
of
us-
are
all
around
the
place:
let's
go
a
sink.
Who
wants
to
meet
at
midnight?
Who
wants
to
wake
up
at
7am
in
the
morning?
Have
meetings
without
coffee,
so
we
thought,
let's
create
a
slack
Channel,
so
we
created
a
slack
Channel
in
May,
2022
or
2021
on
22nd
May,
but
it
was
still.
A
We
didn't
really
get
anywhere,
eventually
Robert,
who
was
one
of
the
six
security
and
tax
security
members.
Just
like
me
almost
asked
us:
wouldn't
it
not
make
sense
to
have
maybe
one
meeting
where
we
just
talk
figure
out
what
needs
to
be
done
and
then
go
a
sink.
Maybe
that
will
trigger
and
kick
start
things
for
us.
So
we
did
that
and
our
first
meeting
was
actually
on
August,
which
is
about
you
count
three.
A
Four
months
after
we
created
the
slack
Channel
and
again
with
kubernetes,
just
creating
a
slack
Channel
needed
a
GitHub
issue,
because
you
don't
get
to
create
your
own
slack
channels.
Since,
obviously,
we
have
to
follow
the
process,
that's
established,
you
get
to
ask
the
wonderful
people
in
sick
contracts
to
create
those
things,
and
then
we
had
that
slack
Channel
by
just
creating
a
printable
issue,
which
was
great.
A
B
So
what
I
did
is
I,
so
we
had
our
first
meeting.
We
decided
to
do
some
stuff.
Asynchronously
I
took
a
look
at
what
some
of
the
other
graduated
projects
who
had
gone
through
the
process
have
done,
and
one
of
the
things
I
noticed
is
a
lot
of
them
had
done
this
sort
of
self
review
of
their
secure
software
development
practices.
So
this
was
initially
under
the
core
infrastructure
initiative,
but
it's
been
moved
under
the
open
source
security
Foundation.
B
If
you
are
maintaining
of
a
project,
you
can
just
go
in
you.
You
just
sign
in
with
your
GitHub
ID,
and
you
start
thinking
in
questionnaire
and
it
sort
of
asks
you
you
know.
Are
you
doing
Securities?
Are
you
doing
one
inventory
scanning?
Are
you
doing
static
analysis?
If
you
code,
what
are
your
processes
for
contributions?
Security
reporting,
so
I
just
build
it
out
sort
of
like?
Are
we
doing
those
things
for
plus
API?
You
can
see
that
the
current
status
is
not
quite
100.
B
B
Yes,
so
that's
the
wrong
way
round.
That's
why
right
next
things,
data
flow
diagram,
so
I
thought
I
would
get
this
go
asynchronously,
so
data
flow
diagrams
are
way
of
modeling
components
within
the
system
where
information
is
traveling
between
them.
That
can
help
a
security.
Analyst
determine
threats,
find
weak
points
in
there.
So
I
thought:
oh
yeah,
that's
easy!
I'll
just
do
it
ended
up
with
basically
a
spaghetti
meatball
and
that's
when
I
thought.
Maybe
we
need
some
help
here
doing
this
properly
yeah.
B
So
first
thing
we
did
is,
let's
think
about
scope
So
to
avoid
spaghetti.
Meatballs
situation,
maybe
like
let's
focus
on
some
key
key
areas
now,
plus
the
apis
got
a
lot
of
different,
covers
a
lot
of
different
infrastructure.
You
might
have
just
seen
an
announcement
about
Cloud
stack,
Apache,
Cloud
stack
being
added
yes,
two
days
ago
by
Amazon,
so
can't
deal
with
all
of
those
interactions.
Let's
keep
it
close.
B
We
could
look
at
sort
of
Hardware,
Trust
Systems,
because
you're
creating
nodes
and
how
are
they
authenticating,
how
they?
How
are
they
proving
their
identity,
tenant
boundaries,
so
you've
got
different
clusters
in
the
same,
like
maybe
the
same
Amazon
account
or
the
same
Google
project
like.
Maybe
you
can
jump
across
different
clusters.
B
Cool
kubernetes
components
should
have
already
been
covered
in
the
main
kubernetes
audit.
That
was
done
a
few
years
ago
by
trailer
bits,
so
we
didn't
that
could
be
excluded
and
finally,
certificates
like
we
do
a
lot
of
certificate
stuff.
So
I
work
on
Amazon
in
particular
also
I
work
at
VMware
I
did
not
want
to
make
this
a
sort
of
a
VMware
Fest.
We
could
have
said
oh
yeah,
let's,
let's
look
at
vsphere
that
not
be
appropriate
right,
like
don't
want
to
make
it
a
sort
of
one
render
show.
B
We
know
Amazon's
the
most
popular
used
plus
the
API
project.
So
that's
the
one
that
we
went
for
yeah.
So
as
I
mention,
we
we've
ordered
on
the
kubernetes
security
review
and
one
thing
about
scope:
Amazon
already
has
a
shared
responsibility
model,
so
there's
no
point
covering
things
which
are
really
the
responsibility
of
the
cloud
provider
like.
Oh,
what
happens
is
someone
steals
a
hard
drive
from
Amazon's
data
center?
We're
not
interested
in
that
there's
nothing.
B
We
can
do
about
that
as
as
a
cluster
API
as
a
kubernetes
sub
project,
so
keep
the
scope,
manageable
and
sustainable
yeah.
So
we
took
a
slice
through
the
system,
so
we
were
mostly
so
if
we're
creating
clusters
we're
mostly
creating
machines,
creating
kubernetes
control
planes,
out
of
them
putting
joining
machines
to
that
cluster.
So
that
covers
a
large
enough
slice
through
different
systems
like
kubernetes
itself,
the
cloud
provider
and
then
that
sort
of
stack
the
scope
of
what
we're
doing
so.
B
That
stage
is
like
okay,
don't
want
to
do
the
spaghetti
meatball
again.
So,
let's
start
having
some
meetings
and
have
they
do
security
push
go
and
Robert
join
us.
We
recorded,
or
we
say
we
set
up.
Some
team
calls
they're
all
recorded
they're,
all
on
YouTube
they're
still
there
people
want
to
do
them
and
I'll
probably
go
to
tell
you
how
to
do
data
flow
diagrams
properly.
A
Yeah
so
huge
shout
out
to
Excalibur,
which
is
what
I
used
to
draw
this
diagram.
It's
still
a
complicated
diagram
like
I,
won't
lie,
but
it
felt
better
than
what
we
had
started
with
and
the
idea
was.
If
we
have
narrowed
the
scope,
the
complexity
is
going
to
kind
of
go
away,
and
once
it
is
simpler,
then
it
is
easier
to
poke
holes
into
the
flow.
What
if
this
particular
component,
that's
represented
in
this
block,
diagram
gets
compromised.
What
do
we
do?
A
What
if
there
is
a
man
in
the
middle
attack
between
two
components,
interacting
with
each
other?
Is
there
a
sensitive
data,
that's
being
transferred
over
TLS
or
without
TLS?
What
happens
if
I
escalate
my
privileges
to
admin?
Do
I,
have
more
control
and
can
I
do
more
things
as
a
malicious
Insider.
So
all
of
those
questions
and
which
is
what
we
ended
up
asking
another
Ankita
and
so
many
others
in
cluster
API.
They
were
very
patient.
A
So
what
better
way
to
write
everything
down
to
start
the
discussion
than
Google
Docs,
where
you
can
comment,
add
suggestions
and
have
much
more
of
an
async
discussion
after
like
multiple
hours
of
meetings
that
had
the
data
flow
diagram
as
its
output,
so
we
shared
it.
We
also
started
documenting
different
threats.
We
used
one
of
the
more
popular
thread,
category
called
stride,
which
is
spoofing,
tampering,
repudiation
information,
disclosure,
elevation
of
privilege
and
I
missed
the
other
one
denial
of
service.
A
So
we
had
the
threats.
We
had
the
initial
data
flow
diagram.
We
had
the
assumptions
clearly
called
out.
We
had
mentioned
the
scope
and
once
we
got
more
feedback
from
the
community
in
cluster
API,
we
also
started
sharing
it
with
six
security,
as
we
became
closer
to
a
realistic
PR,
which
is
a
pull
request
on
GitHub,
we
thought
it
might
be
a
good
idea
to
now
convert
what
we
have
on
a
Google
doc
into
markdown,
because
everything
on
GitHub,
at
least
on
kubernetes
and
CNC
of
spaces,
is
on
markdown.
A
So
we
converted
the
Google
Doc
into
markdown.
It
was
on
hack
MD.
Another
set
of
reviews
happened
again.
This
took
a
few
weeks,
while
we
were
all
doing
our
day,
jobs
all
doing
all
the
other
existing
roles
that
we
are
all
playing
and
then
eventually
we
had
a
draft
PR,
which
was
almost
unbelievable
when
it
happened,
because
it's
been
so
long
since
we
had
charted
this
and
we
could
actually
see
things
in
progress
act
and
being
maybe
helpful
for
the
future.
A
One
of
the
discussions
we
had
in
six
security
is:
this
is
a
massive
document.
It
was
about
1000
plus
words
or
lines,
or
something
like
that,
and
we
wanted
to
see
what
is
the
best
place
to
keep
it.
So
there
were
a
couple
of
ideas:
why
not
keep
the
security
assessment
doc
where
the
code
is
so
that
would
be
kubernetes
slash
cluster
API.
A
Another
idea
was
what,
if
we
do
more
self-assessments
in
future,
wouldn't
it
make
sense
to
have
all
the
self-assessments
in
one
place,
which
is
why
we
ended
up
putting
this
self-assessment
into
kubernetes,
slash
six
security
and
it
had
its
own
dedicated
folder
called
six
security
assessments,
and
then
every
project
would
get
its
own
dedicated
folder.
So
if
you
want,
you
can
take
a
look
at
previous
assessments,
learn
from
it
when
you're
doing
a
future
assessment.
A
A
A
When
I
started,
and
by
the
time
we
had
the
pr
open,
I
had
a
30
70
split
in
favor
of
Upstream,
which
meant
I
could
do
more
of
these
things,
spend
more
time
on
upstream
and
help
not
only
the
people
who
are
in
cluster
API,
but
all
the
end
users
of
cluster
API,
who
are
going
to
benefit
from
any
improvements
we
make
and
for
another
I.
Let
him
speak.
B
Yeah,
sadly,
I
may
be
completely
Downstream,
so
obvious,
still
acting
as
a
consumer
cluster
API,
but
I'm,
not
a
maintainer
at
that
State.
Well,
not
a
maintainable
to
Cluster
API
AWS
project,
which
is
what
I
was
doing
at
the
time.
So
there's
no
point
doing
that
security
audit.
If
there's
like
no
Handover
at
all,
so
at
that
stage,
that's
where
I
pulled
in
the
so
when
we
started
this
I
was
I
was
not
a
maintainable
cluster
API
I
was
just
interested
and
sort
of
driving
it.
B
B
Yep,
so
one
of
the
things
that
we
did
do
for
the
cluster
API
project
is
because
it's
it's
been
used
in
quite
a
lot
of
products.
Today,
it's
like
so
it's
and
it
is
being
used
to
create
kubernetes
classes.
So
it's
not
so
it's
made
the
case
that
is
actually
sort
of
a
security
critical
project
at
this
site.
B
At
this
stage,
so
we
cncf
Robert
very
kindly
helped
us
get
funding
from
the
cncf
to
get
other
Logics
who
do
have
a
talk
later
to
later
today,
not
later
today,
on
Friday
at
4
P.M,
so
I
won't
go
into
details
of
what
we
actually
did,
but
they
spent
a
month
setting
up
fast
testing.
It's
now
running
on
Google's
OSS,
Buzz
infrastructure.
B
So
we
have
continuous,
fast
testing
the
maintainers
get
an
email
every
like
twice
a
week,
saying
found
a
new
Edge
case
and
we
make
a
determination
of
whether
or
not
it's
relevant
or
not
yeah.
So
the
final
outcome
is
well:
we've
got
the
merge.
Pr
we've
got
the
fast
testing
and
one
of
the
other
things
that
we
did
are.
B
All
of
the
core
issues
that
were
found
and
we
filed
as
issues
with
tags,
still
labeled
security,
self-assessment,
they're
all
on
the
cluster
API
project.
Some
days
have
been
dealt
with,
some
of
them
haven't
and
yeah.
So
one
of
the
issues
that
we've
found
is
we
don't
have
a
good
process
for
some
security,
one
ability
reporting
for
kubernetes
sub
projects,
because
the
maintainer
base
tends
to
be
smaller.
So
what
does
it
mean
to
have
like
20,
24-hour
response
time
and
there's
only
three
or
four
people?
B
It's
it's
all
very
well
having
the
kubernetes
core,
which
does
tend
to
have
like
a
larger
maintainer
base
with
a
security
process,
but
there's
all
these
now,
as
we
break
kubernetes
up
into
lots
of
smaller
projects,
we
need
to
do
the
same
thing
now
for
those
sub
projects.
So
we
need
to
figure
something
out.
There.
That's
been
one
of
the
main
stumbling
blocks
and
also
we
probably
need
some
help
with
from
security.
Expensive
prioritize
like
what's
the
most
important
issues
here.
So
there
are
a
bunch
of
security
issues
that
we
found
like
what's
important.
B
A
Yeah,
so
we
finished
clustered
API
assessment.
We
have
a
list
of
things
to
do.
Does
this
mean
it's
over
Well
turns
out.
It
was
the
start
of
something
even
greater.
So
after
the
relative
success
of
cluster
API
self-assessment,
we
thought
why
not
open
it
up
for
everyone,
and
we
actually
are
doing
that
now.
So
there
is
a
talk
tomorrow
from
six
security,
where
we
will
focus
specifically
on
what
the
security
self-assessment
sub
project
does,
how
you
can
get
involved
and
how?
B
So
just
cover
some
like
what
what
do
we
learn
in
terms
of
doing
I,
suppose
across
the
API
project,
so
find
a
code
conspirator,
a
fellow
geese,
a
fellow
vacuum
that
can
help
you
on
your
journey
and
getting
this
Security
review,
make
sure
to
get
maintain
a
buy-in
like?
Don't
just
do
it
by
yourself
outside
and
expect
anything
to
happen.
B
You
need
to
speak
to
the
maintain
if
you're
an
end
user
and
you
you're,
using
it
and
you're
worried
about
security
like
make
sure
you
get
the
maintainers
to
find
them
that
choose
manageable
scope.
You
can't
boil
the
ocean
like
you've,
got
to
start
somewhere
and
then
maybe
once
you've
dealt
with
those
most
critical
things,
you
can
start
extending
the
scope
to
other
areas
of
your
project.
B
Yeah,
you
need
to
balance
like
working
asynchronously
and
synchronously,
like
account
for
the
subject
matter,
expertise
that
you
need
to
bring
in
and
time
zones
yeah.
So
actually
one
thing
we
didn't
talk
that
much
so
one
of
the
things
we
did
during
this
job
thanks.
One
of
the
things
we
did
during
the
drafting
process
is
Portugal
and
Robert
came
out
with
a
bunch
of
attack
vectors.
B
We
came
in
and
actually
reviewed
those
as
well
and
said:
okay,
yeah,
this
one
doesn't
really
make
sense
in
the
context
of
how
the
project
works,
or
this
thing
is
out
of
scope
or
it's.
We
defer
that
element
of
security
to
an
external
project
like
there
are
things
you
can
do
with
Opa
or
caberno
to
secure
the
kubernetes
cluster
with
a
with
something
stronger
than
our
back,
like
there's
limits
to
what
you
can
do
with
kubernetes
crds,
so
making
it
more
meaningful.
B
We
didn't
really
want
to
do
like
security
theater
and
we're
like
you
could
be
well
easy.
We
just
find
a
bunch
of
cve
reports,
whatever
that's
not
terribly
useful.
We
wanted
something
meaningful
that
says
right.
These
are
things
that
are
in
your
architecture
of
the
project,
so
we
were
involved
during
that
whole
report
drafting
process.
It
wasn't
just
simply
external
Auditors,
finding
the
thing
and
then
we
sort
of
just
fix
some
CVS.
Afterwards,
process
works
best
when
there's
render
sponsorships,
though
VMware
was
mostly,
but
it
wasn't
a
formal
thing.
B
B
You
can
just
run
through
the
questionnaire
and
see
where
you
are
and
and
there's
probably
going
to
be
some
easy
things
you
can
do
like
set
up
some
static
code.
Analysis
on
like
GitHub
action
make
sure
the
developers
are
using
MFA
Keys
when
they're
doing
releases,
yeah
and
then
finally,
just
something
we
need
to
figure
out.
Oh
no
yeah,
if
your
critical
project
consider
going
to
OSS
FAST
program,
it's
probably
worth
following
those
instructions
to
implement
the
fuzzers
anyway.
B
But
if
you
are
security,
critical
get
on
to
the
program,
that
means
your
code
is
always
being
fast
tested
continuously
on
Google's
infrastructure,
which
is
great
and
yeah
just
find
a
thing.
We
do
need
to
figure
out
security
reporting
for
the
kubernetes
sub
projects
and
I'm
hoping
the
tag.
Security
and
Security
will
help
us
with
that.
With
that
we'll
open
up
for
questions.
A
Yeah
so
I'll
try
to
summarize
the
question
in
case
it
wasn't
Audible
for
the
people
watching
the
recording
or
watching
the
live
stream
for
folks
who
are
starting
new.
Obviously
you
seem
technical.
What
is
the?
What
would
be
your
recommendations
for
folks
starting
new
who
want
to
do
something
like
this
either
as
a
security,
assessor
or
someone
who
is
a
maintainer
of
a
project,
so
I
want
to
go
with
the
maintainer
part.
First.
B
Actually
I
was
hoping,
wow
I,
think
there's
three
parts
that,
in
terms
of
gangs,
started
with
the
projects
itself,
I
think
that
is
probably
up
to
the
maintainers
to
produce
relevant
documentation
and
if
then,
if
you're
interested
in
the
security
perspective
maintenance.
But
you
need
to
provide
like
some
basic
architectural
like
documentation
about
how
their
stuff
actually
works.
So,
if
you're
but
I,
think
there's
also
a
slightly
different
question
like
even
for
maintainers
themselves:
they're,
not
necessarily
like
security
security
focused
so
I'm,
not
actually
interested.
A
A
It
felt
like
wow,
like
only
the
people
who
are
experts
and
have
hacked
multiple
systems
in
the
past
would
be
able
to
threat
model
turned
out.
It
wasn't
the
case.
I
haven't
hacked
multiple
systems,
but
I
was
I'm
decent
enough
with
red
modeling,
so
your
journey
would
be
different.
I
can
share
my
journey
quickly.
A
For
me,
it
was
cleaning
up
about
what
thread.
Modeling
is
watching
some
well-known,
well-documented
sessions
that
explain
what
threat
modeling
is
how
you
can
get
started
talking
to
people
who
have
done
this
in
the
past
and
telling
them
can
you
can
I
Shadow
you
and
when
you're
doing
threat
models,
so
I
can
see
what
you're
doing
and
then
asking
them.
Can
you
Shadow
me
when
I'm
leading
threat
model,
so
those
things
helped
eventually
one
at
the
once
the
technical
piece
was
done.
A
The
harder
piece
I
felt
was
there
is
always
that
Unwritten
rule
where
developers
are
not
very
happy
with
the
way
security
people
think
they
are
and
how
security
people
are
not
happy
with.
The
way
developers
think
they
are
so
in
the
beginning.
One
thing
I
promised
myself
is
I'm
not
going
to
be
here
to
stop
block
and
shame
cluster
API
team.
The
main
idea
was:
how
can
I
be
friends
with
them?
How
can
I
ask
them
questions
which
are
more
molded
in
curiosity
versus
molded
into.
A
How
could
you
do
this,
or
why
did
you
do
this?
It
was
more
about
I'm
curious
if
this
particular
system
work
this
way
with
this
system.
What
would
happen
so
those
kind
of
discussions
I
think
brought
them
some
level
of
comfort
where
it
felt
like
okay.
This
is
not
a
meeting
where
I
have
to
fight
and
be
defensive,
but
this
is
where
something
good
is
going
to
happen
for
my
project.
So
that's
that's
my
take,
but
your
journey
could
be
different.