►
From YouTube: CNCF Security TAG Regular Meeting - 2021 08 04
Description
CNCF Security TAG Regular Meeting - 2021 08 04
A
B
C
C
A
C
I
haven't
had
mine
chewed
on
by
a
cat,
but
in
a
different
meeting
work.
One
months
and
months
back,
I
was
holding
my
one-year-old
and
the
little
pieces
dangling
out
there.
It
has
like
a
little
a
little
foam
ball
on
it
or
something
oh
yeah
yeah.
So
he's
like
trying
to
like
bite
it
off,
welcome
to
the
new
norm,
etc,
get
trying
to
devour
your
headset
yeah
par
for
the
courts.
C
A
B
A
D
A
A
A
A
A
B
I
could
introduce
myself,
I'm
I'm
you.
I
just
wanted
to
join
and
yeah
see.
What's
what's
going
on,
I'm
I'm
mark,
I'm
I'm
from
switzerland.
I
work
for
tnm,
it's
a
software
company
yeah
in
in
zurich
and
I'm
a
software
engineer,
but
mainly
mainly
involved
in
cloud
projects
and
I'm
I'm
interested
in
cloud
native
technology,
and
I
thought
I
would
like
to
yeah
join
and
contribute
to
one
of
the
tags,
and
I
think
security
is
quite
interesting
and
I
already
went
through
all
the
the
topics
and
open
issues
on
github.
A
B
A
Awesome
thanks
axel
yeah,
actually,
I've
seen
you
around
for
the
past
two
meetings,
it's
great
cool
and
also
quick
reminder
for
those
that
have
joined
the
the
past
few
meetings.
You
know
for
like
a
month
or
two
do
feel
free
to
add
yourself
as
a
pr
to
the
memphis
list.
On
the
main
page,
there
is
a
membership
in
the
main
page,
it's
hidden
behind
the
expandable
section,
but
yeah
welcome,
mark
and
excellent.
A
All
right
so
moving
forward
review
of
other
time
zone
security
time
meetings.
I
don't
think
we
had
anything
on
eight
night
for
last
time,
so
we
haven't
scripted
that
toc
meeting
updates.
We
did
an
update
the
regular
tech
security
update
on
tuesday
because
it
went
well.
There
was
good
feedback
on
the
pr
that
we
have
with
the
security
resources
like
the
security.md
page
and
things
like
that.
They
are
working
for
us
to
upstream
that
to
contributing
the
sick,
contributing
and
contributing
resources
that
we
have
on
cncf.
A
C
Sure
rob
fighlia
and
myself
the
other
day
had
another
meetup
with
the
cloud
custodian
team
just
going
through
the
joint
review,
populating
it
assigning
ownership
of
sections,
and
am
I
coming
through
brennan,
okay,
yeah
just
assigning
ownership
to
some
remaining
sections.
I
already
did
a
call
for
reviewers
to
see
if
anyone
wanted
to
populate
the
the
threat
model,
section,
there's
already
the
self-assessment
variant
of
that
and
we're
just
copy
pasting
it
in
and
getting
whatever
material
we
can
fill
in
there.
C
And
last
but
not
least,
my
understanding
is
next
week's.
Iteration
will
be
our
last
one.
If
I
have
that
correct
for
a
cloud
custodian,
sometimes
abbreviated,
c7n
and
I
believe,
we'll
have
the
remaining
pieces
in
there.
I
do
not
believe
we'll
be
doing
a
hands-on
assessment
like
benchtop
testing
and
all
that,
but
that
should
pretty
much
conclude
the
last
of
what
we
have
to
do
with
it
for
this
foreseeable
future.
C
B
B
A
B
I
expect
this
to
work
and
it's
not
working
okay,
so
we've
you
know,
we've
obviously
looking
at
the
you
know,
cfps
to
kind
of
determine.
Obviously
the
you
know
the
choices
for
that
we
went
through
that
with
a
fine-tooth
comb.
It's
it's
been,
there's
been
amazing
submissions.
I
mean
just
it's
my
mind's
blown
from
the
amount
of
great
submissions
we've
had
we've
talked
this
morning
in
terms
of
logistics
around
the
ctf,
which
was
really
cool,
which
is
obviously
one
of
our.
B
A
A
D
B
D
Go
first,
you
know
thanks
for
having
me
I'll,
introduce
myself
a
little
bit
and
then
we'll
get
to
it.
Motivation
for
kind
of
giving
this
talk
and
andreas
is
the
one
that
put
me
in
in
in
touch
with
with
this
group
and
said,
like
come
talk
a
little
bit
about
this
stuff,
but
my
background
and
kind
of
the
things
I
did
before
got
me
in
the
position
to
have
some
of
the
conversations
I
have
now.
D
Obviously,
because
that's
the
thing
and
then
transitioned
to
red
hat
about
two
years
ago,
not
quite
two
years
ago,
in
parallel
to
that,
I've
been
organizing
events
and,
like
part
of
these
communities
as
a
participant
and
as
a
community
builder,
organized
devops
days,
wrote
some
books
for
o'reilly
on
web
operations.
I
wrote
it
forward
in
the
sre
book
that
google
just
published-
and
you
know
just
have
a
bunch
of
experiences,
scar
tissue
opinions
and
I'm
going
to
share
some
of
that
lesson
today.
D
So
the
the
next
slide
is
is
really
just
to
show
you
my
peak
pandemic
beard
and
hair,
because
that's
very
important
and
then
this
one
is
critically
important
because
it's
my
twitter
handle
and
my
and
my
name.
So
if
you
want
to
reach
out
on
linkedin
or
twitter,
hit
me
up,
and
we
can
talk
about
this
stuff
more.
D
D
I
don't
really
consider
myself
a
security
expert,
but
what
I
have
become
fascinated
with,
as
as
security
as
a
constraint
which
I'll
talk
through
the
rest
of
this,
is
that
you
you
run
into
security
as
a
ball
neck,
as
you
make
all
these
investments
in
in
automation,
whether
you're
talking
about
the
older
style
of
automation,
with
things
like
puppet
or
the
new
container
platforms.
At
some
point,
the
bottleneck
is
all
these
practices
around
security.
So
what
I
consider
myself
is
a
pattern
matcher
and
puzzle
solver.
D
I
really
like
solving
puzzles
and-
and
this
constraint
this
ball
neck
over
and
over
and
over
you
run
into
this,
especially
in
regulated
environments
where,
if
you,
if
you
have
the
old
style
for
everything,
then
a
deployment
might
take
months
so
having
this
process
of
inspection,
it's
the
security
cost.
If
you
will
be
two
weeks
or
one
week
or
whatever,
is
not
noticeable
when
you're
baked
into
that
bigger
process.
D
But
as
you
get
to
where
you
can
make
decisions
on
the
order
of
seconds
like
we
can
now
with
some
of
the
cloud
services,
then
having
that
kind
of
overhead
for
every
deployment
is
just.
Is
just
a
crazy
cost
right,
so
you
think
about
if
you,
if
you
think
about
the
movements
of
the
last
10
years,
you
have
deployments
in
in
time
with
continuous
and
delivery
and
then
deployments
in
space
with
microservices.
D
If
you
have
a
very
heavyweight
and
inspection
driven
security
posture
to
to
all
of
those
deployments,
then
that's
going
to
be
a
bad
time
and
you're
not
going
to
get
good
results
either.
You
like
literally,
can't
keep
up
with
this.
So
this
is
the
this
is
the
short
version
burning
your
head.
That
security
is
not
really
a
thing,
it's
not
yes
or
no!
It's
it's
a
qualitative
thing
right
and
there's
there's
no
one
at
lea
at
least
people.
I
consider
good
at
this
that
believes
that
you
can
quote-unquote
be
secure
right.
D
It's
a
it's,
a
question
of
the
adversaries.
It's
the
question
of
the
risk
and
the
profile,
and
I'm
gonna
make
a
bunch
of
analogies
back
to
reliability
like
like.
If
you're
talking
about
reliability
and
making
investments
in
reliability,
every
nine
of
reliability
costs
you
10
times
more
than
the
last
one.
So
so
at
what
point?
Does
it
make
sense
to
keep
investing
investing
in
security
proportional
to
the
risk
of
the
of
the
assets
you're
protecting
then?
The
second
point
is
that
security
is
not
it's
not
a
quality
of
the
technology
by
itself.
D
So
this
is
legacy
andrew
2010,
I
wrote
a
blog
post
because
there's
a
bunch
of
people
talking
about
devlops-
and
I
was
one
of
them
and-
and
this
is
sort
of
the
devops
version
of
2010
from
andrew,
so
developers
operations
can
should
work
together.
System
administration's
evolving,
look
more
like
software
development,
evolving.
Together
as
a
global
community
sharing
solution,
I
think
the
third
point
is
actually
the
most
interesting
and
exciting
to
me.
D
I
think
that
we
have
the
same
opportunity
with
security
and
especially
you
know
the
types
of
communities
and
conversations
we're
having
right
now,
but
the
second
one
is
interesting,
and
you
see
like
basically
system
administration
in
the
old
old
world
was
like
lots
of
toil
lots
of
tasks.
Lots
of
work
was
done
and
then
coming
into
2010.
You
could
provision
systems,
you
could
configure
systems,
you
could
monitor
systems
all
apis
running
to
apis,
look
suspiciously
like
software
development,
but
you
have
this
resistance
in
system
administration,
communities
to
doing
work.
D
So
this
is
me
again
like
in
the
before
times
when
you
could
leave
the
house
giving
giving
a
talk
at
a
conference,
and
this
is
a
definition
I
use
many
times
for
what
devops
means
to
me
right.
So
this
is
sort
of
like
a
newer
version.
It's
optimizing
the
human
experience
and
performance
operating
software
with
software
and
with
humans,
and
just
to
be
like
fully
buzzword
compliant.
This
is
sort
of
what
I
try
to
help.
People
do
right
so
continuously
devops
micro
serverless.
D
D
The
motivation
is
to
change
something,
so
they
can
get
an
advantage
and
then
what
what
happens
is
a
certain
point
in
the
in
the
side
come
into
the
majority.
Is
that
you're
no
longer
seeking
an
advantage,
you're
actually
seeking
legitimacy
right?
So
you
have
these
practices,
they're
advanced,
seeking
and
and
they
get
an
advantage
right.
So
you
see
things
like
the
the
state
of
devops
report
and
it
says
so
all
these
metrics
and
so
then
people
are
like.
Oh
that's
legitimized,
and
so
then
they
start
changing
the
name.
D
You
see
this
over
and
over
with
a
lot
of
these
movements
right,
so
it's
like
agile
practices
didn't
really
cross.
The
chasm
like
the
future
future's
here
for
all
this
work
for
all
the
security
stuff,
but
it
hasn't
really
come
into
the
future
in
an
evenly
distributed
way.
So
what
can
we
do
to
accelerate
this?
So
I'm
not
going
to
talk
about
all
this
stuff.
Hopefully
this
stuff,
you
all
talk
about
all
the
time
or
have
some
knowledge
of.
D
So
it's
like
a
meta
talk
around
this
and
I'm
not
not
going
to
talk
about
it
either.
I
think
there's
starting
to
be
some
some
clarity
on
this
vision
of
how
this
stuff
all
fits
together.
Where
you
have
you
know
some
strong
identity,
you
have
some
promises.
You
can
keep
about
the
verifiability
of
the
deployable
artifacts
and
all
those
pieces
are
kind
of
coming
together
in
a
nice
way
and
I'm
I'm
as
excited
to
kind
of
consume
that
and
help
other
people
implement
that
as
anyone.
D
But
I
don't
necessarily
talk
to
you
so
from
the
very
beginning
like
I,
I
don't
think
that
the
principles
of
a
lot
of
this
stuff
has
changed
right.
So
you
know
back
in
the
in
the
puppet
days
like
puppet
acted
like
a
certificate
authority
and
one
of
the
one
of
the
most
difficult
things-
and
you
know
we
didn't
have
spiffy
at
the
time
is
like
how
do
you
manage
identity
for
the
agents?
D
Everything
that's
happening
in
these
infrastructures
and
there's
stuff
that
you
know
the
company
I
work
for
is
doing.
That
is
related
to
this
there's.
There's
conversations
I'm
having
with
people
across
the
industry
that
I
think
are
interesting.
You
know
I
talked
to
andreas
quite
frequently.
He
he
works,
for
you
know
in
theory
the
our
biggest
competitor.
So
that's
fine.
So
this
is
not
really
that
different
in
the
sense
that
people
always
try
to
solve
authorization,
authentication
problems.
We
just
have
better
tools.
D
We
just
have
a
kind
of
like
more
advanced
way
to
do
it,
and
this
is
this
to
me
like
when
people
start
talking
about
zero
trust.
I
I
think,
when
you
actually
start
reading,
there's
like
a
lot
of
trust
everywhere
like
there's
the
word.
Trust
is
used
quite
explicitly
all
over
the
place,
but
but
what
you're
getting
to
is
this
verified
version
of
things
where
you
know
you
can
keep
strong?
You
know
even
cryptographic
promises
about
what
is
happening
where
the
old
style
of
doing
this
was
was
about
toil.
D
So
that's
like
a
big
part
of
all
this
stuff
for
deploying
deployment
for
monitoring
for
every
every
one
of
these
little
pieces
is
becoming
more
about
software,
more
about
service,
less
about
humans,
doing
repetitive
tasks
and,
and
then
what
we're
part
of
and
what
we're
having
conversations
today
is
software
is
eating
software
security.
As
well,
so
what
does
that
mean?
D
Well,
we
have
this
world
that
we've
built
collectively
built
together
super
computers
everywhere,
connecting
all
human
knowledge
to
high-speed
networks,
but
also
to
adversaries
and
every
aspect
of
human
performance
and
experience
can
be
that
can
be
optimized.
This.
This
is
sort
of
my
definition
of
devops
is
about
how
things
are
optimized,
it
will
be
optimized,
and
that
includes
owning
you,
and
this
is
an
arms
race
right.
So
you
know
kind
of
like
an
update
to
the.
The
previous
thing
is
like
all
these
roles
can
work
together.
D
What
looks
like
security
like
there's,
the
the
dev
sac
part
of
it?
Is
you
you
need
to
develop
these
things,
but
you
also
need
to
connect
them
to
to
the
operations
and
the
rest
of
these
other
selfless
interests
and
there's
a
bunch
of
lessons
that
you
don't
have
to
learn
the
hard
way,
because
we
can
participate
in
these
global
communities
and
reuse
the
the
things
that
other
people
like.
So
this
is
a
pretty
famous
quote
in
in
kind
of
like
devops
conversations
from
2006.,
so
verner
vogels
I'll,
just
read
the
first
part.
D
So
traditional
models,
you
take
your
software,
the
wall
that
separates
development
operations,
throw
it
over
and
then
forget
about
it,
not
at
amazon.
You
build
it,
you
run
it
right.
Like
people
say
this
all
the
time
it's
like
okay
and
I
think
people
get
confused
about
what
verner
means
and
what
the
situation
was
like
at
amazon
in
2006..
D
D
He
doesn't
mean
like
at
the
time
when
he
says
that
in
2006,
ec2
is
launched
and
there's
a
bunch
of
infrastructure
as
a
service.
That's
already
been
built
up
and
and
every
single
one
of
these
companies
has
this,
which,
as
a
point
I'll
make
in
a
minute
that
those
those
developers
aren't
provisioning
and
operating
their
own
databases,
they're,
not
provisioning.
You
know
operating
systems
all
this
kind
of
underlying
infrastructure,
they're
they're,
really
just
worried
about
that
top
layer,
and
now
the
rest
of
that
is
sort
of
done
for
them
right.
D
So
this
is
a
kind
of
a
classic
devops
framing
of
what
came
to
be
known
as
the
wall
of
confusion,
which
just
came
from
talks.
I
gave
a
long
time
ago,
so
traditional
I.t
and
there's
usually
like
a
build
up
and
it's
like
you
communicate
through
ticket
systems.
You
don't
even
see
each
other's
human.
It
makes
people
mischievous
right.
D
So
this
is
what
jabe
and
his
research
and-
and
I
try
to
give
jade
credit,
because
also
if
people
do
academics,
then
they
like
it
when
their
work
is
referenced.
So
he
he's
a
phd
at
carnegie
mellon
focus
on
how
organizations
change
their
behavior
to
take
advantage
of
technology
and
what
he
talks
about.
Is
this
three
economies
on
the
interest,
the
third
one
in
a
minute,
but
the
two
are
what
he
calls
differentiation
economy
and
the
scale
economy
and
and
to
sort
of
oversimplify
it
and
we'll
just
go
super
fast.
D
To
get
to
more
ideas
in
a
minute
is
like
one
side's
trying
to
create
more
value
and
one
side's
trying
to
drive
down
cost.
So
you
could
say
you
know
one
side's
trying
to
destabilize
this
and
our
tri
side
is
trying
to
stabilize
it.
And
you
see
this
play
out
in
organizations
as
a
tension
between
you
know,
business
units
and
I
t
operations
all
the
time
and
those
two
games
kind
of
like
force
us
to
be
against
each
other.
D
If
you
get
really
deep
into
this,
like
you
start
to
realize,
sometimes
the
risk
and
compliance
people
aren't
on
the
same
page
as
the
security
people
either.
But
we'll
we'll
pretend
it's
it's
just
simple
for
a
minute.
So
there's
there's
these
walls
of
confusion
between
these
different
roles
because
they
have
a
selfish
understanding
of
what
they're
trying
to
optimize.
D
They
don't
really
realize,
or
some
of
the
worst
cases
care
what
anyone
else
is
doing,
because
they're
they're
doing
their
quote-unquote
job
right.
So
can
we
win
all
these
games
together?
I'm
gonna
argue
we
can
and
that
there's
a
new
way
to
play
and
and
the
new
way
to
play
is
very
much
related
to
these
communities
that
we're
talking
about
with
the
cncf.
D
So
hopefully
we
can
make
this
more
concrete,
but
this
is
this
is
to
me,
like
this
money,
shot
that
I've
sort
of
reimagined
all
the
devops
conversations
from
the
last
decade
through
this
lens
that
this,
this
scope
economy
results
from
an
ongoing
negotiation
between
all
of
these
selfish
interests
in
favor
of
the
collective
interest
right.
So
if
you
go
back
in
time
to
all
the
all
the
conversations
all
the
projects
around
automation,
you
know
go
back
to
puppet
chef
ansible.
What
have
you
before
you
even
get
to
containers,
but
it's
still
the
same
thing.
D
Then
then
it
was
always
trying
to
enable
innovation
and
keep
promises
to
operations
and,
to
the
extent
that
you
had
these
conversations,
that
you
drove
that
kind
of
meaningful
collective
interest
into
the
manifestation
of
the
of
the
platform.
You
got
good
results
and
you
see
this
carry
on
into
the
container
kubernetes
conversations
where,
if
you
have
a
quote-unquote
platform
team
that
has
a
you
build
it
and
it
will
come
mentality,
but
doesn't
include
the
selfish
interests
of
the
developers
line
of
business
that
they're
trying
to
build
that
platform.
D
For
then
you
don't
always
get
the
the
adoption
that
you
imagined
you
would
right,
and
so
so,
like
the
game
that
I
try
to
help,
people
play
and
understand
here
is
the
more
you
can
bring
those
agents
to
the
table
to
have
that
ongoing
negotiation
about
what
our
actual
needs
are.
What
does
success
look
like
for
us?
Then
the
better
results,
you're
gonna,
get
with
your
initiatives
so
trying
to
make
it
more
concrete.
There's
things
that
begin
as
an
innovation
that
more
might
be
more
valuable
in
that
shared
platform.
D
You
have
this
other
side,
where
there's
probably
resources
that
are
overly
restricted
in
the
in
the
current
practices.
That
would
be
more
valuable
if
they
were
in
kind
of
like
this
pre-audited
configuration
part
of
the
shared
platform
where
developers
could
have
self-service
access
to
do
the
work
they
wanted
right.
D
So
this
is
straight
from
the
sre
book:
sre
build
framework
modules
to
implement
canonical
solutions
for
the
concerned
production
area.
As
a
result,
development
teams
can
focus
on
the
business
logic,
because
the
framework
already
takes
care
of
correct
infrastructure
use.
This
is
google
explaining
how
they
built
their
shared
platform,
the
scope
economy
contract.
I'm
going
to
argue
and,
and
I'm
sure
some
of
you-
I
hope
some
of
you
have
read
the
board
paper.
D
The
borg
is
really
the
scope
economy
construct
that
manifests
itself
at
google
kubernetes
as
sort
of
the
the
daughter
of
borg.
The
spiritual
evolution
board
is
a
scope,
economy,
construct
yay,
and
then
this
is
this.
Like
kind
of
like
the
thing
I
think
about
it's
interesting
is
that
kubernetes
is
this
open
source
global
commons
to
build
these
local
shared
platform
commons
and
if
you're
familiar
with
slo,
I
told
you
I
was
going
to
borrow
from
reliability
and
drag
it
back
like
the
slo
process
and
setting
up
an
slo.
D
Is
this
commoning
exercise
this
this
negotiation
between
the
software
engineers
and
sre
about
about
what
the
service
level
should
be
right?
Are
we
are
we
willing
to
invest
10
times
more
to
get
to
the
next
nine
for
the
service
level
of
the
service
or
not?
Based
on
you
know
the
value
that
we're
creating.
So
what's
the
what's,
the
equivalent
negotiation
for
securability
and
and
what
are
the
principles
of
securability?
D
So
so,
in
thinking
about
this
and
like
how
I
want
to
form
this,
I
wouldn't
say
this
is
like
the
a
super
well
formed
thought,
but
this
was
something
that
had
a
huge
impact
on
me
10
years
ago
over
10
years
ago,
watching
joe
armstrong,
give
this
talk
the
six
laws
of
liability
and,
and
that
I
I
kind
of
like
borrowed
this
a
lot
of
work.
I
did
and
a
lot
of
talks
I
gave.
But
now
now
you
have
like
almost
like
full
genres.
D
Subgenres
of
devops
that
are
like
just
focus
on
so
like
observability,
is
basically
failure,
detection
and
fall
determination,
most
of
what
people
are
doing
with
their
kind
of
like
microservices
platformy
kubernetes.
Things
is
really
about
building
in
isolation,
concurrency
and
live
code
upgrade
stable
storage.
You
know
we're
still
working
through
that,
but
that
that's
critical
for
the
model
that
the
the
principles
that
joe
sets
up
here,
because
you
need
to
be
able
to
trust
that
you,
when
you
write
something
you
can
get
it
back
to
be
able
to.
D
So
so
I
don't
know
where
this
is
going,
but-
and
maybe
we
can
I'll
I'll
kind
of
like
work
on
this
and
have
a
conversation
about
it,
but
this
is
me
being
silly
on
on
twitter.
I
believe
this
very
strongly.
I
said
this
in
2014.
I
think
it's
still
true
kind
of
like
watching
this
evolve,
that
any
sufficiently
complicated
microservice
deployment
contains
an
ad
hoc
in
from
informally
specified
bug,
written
implementation
of
half
of
erlang.
D
If
you
really
go,
look
at
how
erling
was
implemented
and
beam
as
a
runtime
works,
there's
a
lot
of
these
principles
of
reliability
like
baked
into
the
runtime.
So
this
is
this
is
permission
to
find
good
ideas
where
they
are
and
and
steal
them
right.
So
I
I
love
this
and
that's
great
thing,
so
this
is
stealing
from
another
thing.
D
This
is
the
from
the
the
reliability
or
the
sre
book
that
google
published
these
these
chapters,
no
matter
what
your
role
is
in
a
software
organization,
the
the
principles
chapters
of
the
first
sre
book
are
solid
gold
and
it's
these
three
titles,
and
if
you
haven't
read
that
I
recommend
you
do
it,
you
can
read
it
for
free
it'll.
Take
you
probably
half
an
hour,
but
especially
from
a
security
perspective.
D
What
is
the?
What
is
the
risk
that
you're
willing
to
to
do?
How
are
you
making
it?
So
this
is
not
a
manual
process
and
then
what
is
the
appropriate
level
right?
So
this
is
borrowing
that
quote
and
kind
of
reframing
it
security
engineers
built
framework
modules
to
implement
canonical
solutions
for
the
concerned
production
area.
As
a
result,
development
teams
can
focus
on
the
business
logic,
because
the
framework
already
takes
care
of
security
considerations
right.
D
D
So
so
how's
that
platform
get
implemented.
So
this
is
this
is
like
a
quick
101
version
of
wardley
simon
wordley.
Does
this
thing
called
worldly
mapping
and
it's
like
not
the
point
I
want
to
make
today,
but
this
is
kind
of
an
interesting
thing
and
the
one
thing
I
want
to
focus
on
here
is
he
separates
the?
Why
of
purpose
from
the
y
of
movement
right?
D
So
so,
like
the
analogy
uses
when
he
sets
up
this
in
his
book,
is
the
wire
purpose
is
to
win
the
game
right
so
he's
using
this
analogy
of
chess
and
and
why
purpose
is
clear,
like
you
want
to
win
the
game,
the?
Why
of
movement
is
less
clear
and
and
in
particular,
when
you're
looking
at
chessboard,
you're
evaluating
position?
D
What
what
level
of
understanding
you
have
about
a
bunch
of
different
principles
will
determine
what
piece
you
decide
to
move
right
because
you
can
only
move
one
and,
and
so
that's
like
a
kind
of
like
a
deeper
wire,
a
different
way
than
white
purpose.
Why
purpose
is
very
simple,
very
clear
and-
and
I
think
this
is
where
a
lot
of
organizations
sort
of
stops
like
they
put
their
values
on
the
wall?
Here's
why
we're
here,
but
then
they
they
don't
have
good
wise
of
movement
and
they
don't
connect
otherwise.
D
D
I
have
all
these
other
things
that
I
come
to
work
and
I
I
take
some
pride
in
my
craft
and
I
take
some
pride
in
the
work,
but
I
also
have
all
these
other
y's
that
kind
of
drive
and
then
to
the
extent
that
organizations
can
connect
each
of
those
individual
agents
and
the
y
that
they
have
to
those
larger,
wise,
the
better
results
they're
going
to
have,
and
then
someone
has
to
do
actual
work
right.
So
this
is
this
is
the
what
like?
What
do
we
do
and
that's
where
the?
D
D
D
Do
it
it's
like
get
the
the
the
security
conversations
much
earlier
in
the
process,
get
the
security
posture
the
risk
profile
as
part
of
that
platform,
building
commoning
the
interest,
bring
that
bring
the
selfish
interests
of
security
into
the
conversation.
Sometimes
people
like
to
say
shift
left.
I
think
that
that
anchors-
everything
on
languages
that
read
left
to
right,
so
I
like
to
say,
shift
forward.
We
want
to
bring.
We
want
to
bring
these
conversations
earlier
and
earlier
the
selfish
interest
earlier
and
earlier
into
what
gets
built.
D
D
You
have
the
these
platforms
that
keep
promises
to
those
developers
enabling
them
with
that
self-service
access,
and
then
you
have
these
securable
kind
of
compute,
networking
and
storage
primitives
underneath
that
that
do
all
the
things
they
need.
So
sometimes
people
say
stuff
like
this
to
me
and
I'm
just
like
cool
story,
because
this
is
never
really
done
like
devops.
Never
done
security's,
never
done
it's
an
ongoing
process
to
improve
the
quality
that
the
socio-technical
system
that
you're
actively
building
can
can
do
right.
So
you're
continuously
doing
it.
D
So,
as
you
think
about
the
adoption
and
kind
of
the
arc
of
the
narrative,
you
know
seeing
some
of
the
exciting
things
that
you
all
are
working
on.
Understand
that
resistance
to
change
the
only
thing
more
inevitable
than
change
right.
So
so,
like
you,
you
meet
organizations
and
they're
like
we
would
really
like
to
automate
stuff
and
it's
like
well.
How
long
do
you
think
that
will
take
three
years?
You're
like
okay,
I'll,
try
to
help
you,
but
is
there
some
way
we
could
do
that
a
little
faster
because
I'm
impatient.
D
So
this
is
something
you
run
into
over
and
over.
You
have
these
organizations
and
they
just
do
things
a
certain
way
and
they
don't
want
to
change,
because
that,
like
I
do
security,
I've
done
security
for
decades
like
why.
Why
would
I
do
it
different?
Like
we're,
obviously
secure-
and
I
think,
there's
a
funny
conversation.
This
aside,
I
had
lots
of
conversations
with
people
that
worked
in,
like
you
know,
big
web.
D
You
know
cloud
native
companies,
I
have
lots
of
conversations
with
with
banks
and
and
other
other
kind
of
like
secretive,
three-letter
agencies
or
whatever
and
there's
this
there's,
this
kind
of
weird
dynamic,
where
no
one
who's
worked
in
both
thinks
that
the
the
banks
are
better
at
security
than
the
cloud
natives,
but
sometimes
the
banks
think
they
are
which
is
like.
I
don't
know
fascinating,
but
let's
do
better.
So
this
is
my
advice
to
you
when
you
think
about
this
technology.
D
Adoption
life
cycle,
where
you
work
where
you
want
to
work
legitimacy,
is
whatever
like
we
make
ourselves
legitimate
by
being
legit.
So,
let's
try
to
we
win
games,
seek
advantages
so
kind
of
coming
to
the
end
of
this.
The
this
problem
that
we're
trying
to
solve
with
security
with
reliability,
with
whatever
other
abilities
we
want
to
add,
is
not
a
purely
technical
problem.
It's
also
not
a
purely
social
problem
right,
like
there's
social
engineering
involved,
but
the
technical
excellence
has
to
be
as
big
a
part
of
the
equation.
D
I
think
sometimes
people
swing
the
pendulum
too
far
to
you
know
the
soft
side,
and
so
it's
like
you
want
to
find
that
balance
in
the
middle
and
it's
a
social
technical
problem
and
you
have
to
solve
both
of
them
together.
That's
what
will
give
you
the
results
you
want-
and
this
is
a
very
famous
quote
from
a
very
famous
person.
I
don't
have
time
to
learn
new
things,
because
I'm
too
busy
getting
things
done,
and
hopefully
you
don't
work
with
this
person,
because
this
is
the
least
productive
person
in
the
world.
D
B
D
I
I
got
coffee
right
right
here
I
mean
I,
I
think,
I'm
also
known
for
like
trying
to
cram
like
way
too
much
content
in
30
minute
talks.
I
I
try
not
to
do
that
as
bad
as
I
have
before,
but
there's
a
lot
to
there's
a
lot
to
cover
and
there's
like
lots
of
nuance
to
like
this
is
sort
of
like
the
high
level
platitudinal
version
of
like
you
need
to
have
these
conversations.
You
need
to
get
these
like
selfish
interests
involved
in
doing
this.
It's
simple,
but
it's
actually
not
easy
right.
D
B
And
I
think
that's
absolutely
true
as
well
like
some
of
the
conversations
I've
had
with
leadership
at
various
companies
if
the
conversation
ends
up
going
like
okay,
so
here's
what
we're
doing
with
zero
trust,
here's,
what
we're
doing
with
cloud
native
and
like
people's
the
leadership
and
both
on
the
social
and
technical
side
will
agree
yeah.
This
is
a
really
great
idea.
It's
what
we
want
to
do.
It's
like!
Well,
why
haven't
you?
D
D
If
you
want
to
get
to
the
other
side
of
this,
and
if
you
look
at
what
the
true
cloud
natives
are
are
filing
with
the
sec
in
at
least
in
the
us,
then
then
it's
like
they
they've
reframed
it
as
a
competitive
advantage
and
they're
making
investments
in
that
advantage,
and
so
there's
kind
of
like
this
tension
to
get
through
the
the
thing
that
I
think
is
actually
harder
to
overcome
in.
In
my
experience,
is
this
thing
where
you
go
into
an
organization
and
you're
like
okay?
D
What
are
we
trying
to
do
here
and
they
kind
of
like
map
out
what
they're
doing
and
they
have
a
silo?
That's
a
sre
team,
that's
different
than
the
and
the
devops
team,
that's
different
than
the
devsecops
team
and
they
have
a
different
initiative
for
continuous
delivery
than
they
have
for
microservices.
And
it's
like
all
these
little.
You
can
just
see
this
kind
of
like
game
of
thrones.
D
That's
been
played
with
with
building
silos
around
some
of
these
budgets
and
head
counts,
and-
and
that's
that's
in
my
opinion,
almost
harder
to
work
through
than
people
who,
like.
Oh,
we
don't
have
the
talent
like
you.
Can
you
can
get
talent
like
okay,
like
what
is
the
minimum
viable
investment
you
can
make
in
making
progress
from
a
green
field
perspective?
I
actually
think
that's
easier
to
make
progress
than
when
they
already
have
this
entrenched
thing
and
they
think
they
implemented.
You
know
some
buzzword,
but
but
they
have
like
all
these
silos
about
it.
B
Dude
amazing
conversation
starter.
I
I
really
appreciate
it
and
I
think
this
is
going
to
branch
off
and
fork
into
many
many
different
permutations
fast
forward,
like
we
align
our
selfish
interests
to
the
collective
of
the
greater
community.
What
cautionary
advice
do
you
have
to
avoid
the
tragedy
of
the
comments.
D
D
And
so
so
there
there's
like
a
few
levels
of
collective
here
right,
so
we
so
we
all
have
our
organizational
collectives
and
then
and
then
there's
this
greater
collective
and
I
don't
want
to
get
too
philosophical,
or
maybe
I
do
want
to
get
too
philosophical,
but
like
there's,
some
really
crazy
stuff
facing
planet
earth
right
now
right
when
you
think
about
like
the
larger
global
geopolitical
stuff,
you
know
pandemics,
climate
change,
all
these
other
things.
So
if
we're
not
going
to
start
to
act
in
our
collective
interests,
you
know
align
with
our
selfish
interests.
D
B
D
I
mean,
I
think,
I
think
the
game
like
it's
about
it's
about
the
situational
awareness
right
so
like
there's
a
deeper
treatment
of
that
idea.
In
other
other
kind
of
conversations,
I
have
right
now
where,
if
you,
if
you
have
those
out
of
balance
with
each
other
in
an
organization,
you
can
kind
of
predict
the
pathology
of
the
behavior
right.
D
So
if
you
get
too
out
of
balance
on
the
innovation
economy,
then
you're
creating
lots
of
vulnerabilities
and
lots
of
downstream
operational
burden
for
the
organization,
and
if
you
get
too
out
of
balance
on
the
other
side,
then
you're,
basically
stopping
the
work
that
could
be
done.
So
it's
it's.
It's
more
about
understanding
like
what's
the
chess
board
you're
playing
with
right
now
like
not
not
an
imaginary,
like
chessboard,
not
not
not
like
the
figment
of
whatever
philosophical
just
board
but
like
what
is
the
organizational
reality
of
this?
D
You
know
problem
I'm
trying
to
solve
and
like
what?
What
are
the
interventions
that
we
could
do?
Also,
this
is
another
thing
I
think
leadership
in
most
organizations
really
struggle
with
is
reality
is
not
very
deterministic
like,
like
there's
probabilities
and
a
lot
of
leaders,
for
whatever
reason
prefer
predictability
and
and
planning
things
in
this
kind
of
like
concrete
way
that
doesn't
match
reality
right.
So
so,
as
soon
as
you
make
those
plans
there's
a
few
versions
of
this
quote,
but
like
plans,
never
survive,
first
contact
with
reality
right.
D
So
so
what
I
try
to
help
under
people
understand
is
creating
optionality,
stability.
You
know
whatever
you
want
to
call
it
resilience
so
that
you
can
respond
to
the
the
organizational
mission
so
that
you
can,
whether
that's
a
financial
mission
or
some
of
these
other.
Like
some
of
the
people,
I
work
with.
Don't
necessarily
have
a
financial
problem
they're
trying
to
solve,
but
but
what
is
the?
D
What
is
the
problem
that
you're
trying
to
solve
and
what's
the
best
way
to
make
incremental
progress
towards
that
and
from
a
software
perspective,
I
feel,
like
lots
of
people
get
wrapped
around
the
axle
around
innovation
where,
for
the
most
part,
there's
actually
very
little
information
or
innovation
and
there's
very
little
need
for
innovation.
What
most
organizations
actually
need
and
what
they
really
want
is
the
obvious
solution
to
their
obvious
problems
which
comes
down
to
you.
Have
all
this
data?
D
B
Totally
and
bringing
it
back
to
mark
underwood's,
comment
and
chat
mark,
I
don't
know
if
you
want
to
talk
a
little
bit
about
that.
We,
we
have
not
a
whole
lot
of
time
left,
but
well.
A
lot
of
problems
and
risks
are
domain
specific
as
a
model.
This
still
might
be
like
beneficial
to
identify
well
the
game
theory
as
a
whole.
What
do
you
think.
D
So
I
mean
again
this,
like
almost
deserves
it
another
hour,
to
have
a
conversation
right,
so
so,
like
obviously
there's
domain
specific
things,
there's
corner
cases.
I
made
this
comment
about
the
risk
and
compliance
people
in
the
security
people.
What
what
we?
What
I
think
we're
moving
into
being
able
to
do
and
keep
strong
promises
about,
is
not
necessarily
that
things
are
secure,
but
that
things
are
verified
to
be
in
compliance
with
our
with
our
security
with
our
risk
officer
and
that
that's
a
weaker
promise.
But
I
think
that's
one
that
we
can.
D
We
have
a
hope
of
keeping
with
the
with
the
current
kind
of
tool
sets
that
are
emerging.
So
so
you
still
need.
You
still
need
those
domain.
Experts
right
and-
and
I
would
I
would
take
it
and
and
draw
it
back
to
the
reliability
analogy
I
was
making
all
along
is
there's
no
organization
on
this
planet.
A
D
A
Cool
so
yeah
we
will
we'll
start
the
tread
up
on
the
side.
Channel
folks
can
comment
that
you
know
we
have
crowd
native
security
confirming
up
in
coupon.
I
don't
know
if
you'll
see
that
I
think
a
couple
of
folks
from
us
from
front
attack
as
well
so
yeah.
Hopefully,
hopefully
we
have
another
opportunity
in
chat.
If
not,
this
is
great
and
thank
you
so
much
andrew
thanks.