►
Description
The typical on-prem approach to security has evolved. The cloud has introduced several different layers of managed services that make navigating the security aspects challenging. Multi and hybrid-cloud workloads and the various tool selection options only add to the challenges.
Workload security starts at the design phase with many considerations involved, and there will key security touchpoints throughout the journey. We want to help you navigate the workload security challenges ahead.
In this session, we will discuss:
- The typical infrastructure layers
- How cloud workloads have changed the security process
- How you can identify where you fit in the ecosystem
A
Awesome,
hello,
hi
everyone
thanks
for
joining
it's
march
office
hours,
I'm
mike
foster,
I'm
the
cloud
native
advocate
at
stackrocks
and
I'll
be
moderating
this.
This
next
chat
over
the
next
hour
with
steve
giguere,
steve
jager,
who
is
the
kubernetes
security
advocate
at
stack,
rocks
2.,
so
we're
going
to
have
to
expand
on
those
advocate
titles
in
a
little
bit.
But
before
we
start,
I
just
wanted
to
go
over
some
general
rules
of
engagement,
so
everything's
muted
on
the
viewers
and
it's
an
on-demand
recording
and
everything
should
be
posted
after
the
event.
A
A
If
you
have
any
trouble
with
the
webinar
console
just
refresh
the
browser,
sometimes
it
hangs
a
little
bit
simple.
Refresh
normally
does
the
trick
and
yep
today
just
moving
into
the
topic,
it's
all
about
kubernetes
workflow
security.
So
you
know
I
don't
want
to
take
away
too
much.
I
want
to
introduce
steve
and
let
him
get
into
it.
So
steve
welcome
tell
us
about
a
little
bit
about
yourself
and
what
we're
going
to
talk
about
today.
B
B
That
is
what
I'm
doing
at
stackrocks,
and
but
my
history
goes
kind
of
way
back,
which
is
what
we're
going
to
get
into
today,
because
we're
talking
about
workload,
security
and
it
goes
all
the
way
back
from
before
stackrock's
working
with
software
composition,
analysis,
static
analysis,
all
the
way
back,
even
like
threat,
modeling
and
pen
testing
and
and
live
all
everything
you
would
do
from
the
very
beginning
of
designing
your
application
all
the
way
to
the
end.
So
I'm
very
happy
to
be
here.
This
is
going
to
be.
A
Yeah
awesome,
you
recently
did
a
layer
cake
talk,
so
you
know,
and
without
giving
away
too
much
I'll,
let
you
get
into
it,
but
you
mentioned
seven
layers
of
security,
so
you
know
from
all
the
way
back
into
kubernetes.
Obviously,
things
have
changed
over
the
last.
You
know
30
so
years
that
you've
been
in
the
security
space.
A
B
B
B
If
you
will
so,
there
was
starting
with
the
cloud
so
the
infrastructure
which
existed
prior
prior
to
this
to
see
your
data
center,
the
the
pipeline
itself,
which
is
sort
of
ubiquitous
across
the
entire
thing,
the
application
which
people
are
generally,
I
like
to
think
they're
pretty
savvy
in
terms
of
security,
maybe
I'm
being
generous
there,
the
applications,
friends
and
dependencies,
which
is
a
growing
subject
in
terms
of
open
source,
the
image.
If
we're
talking
about
modernization
and
containerization
the
way
the
image
is
deployed.
B
Every
everything
has
seven
layers,
that's
just
a
yeah,
that's
a
fact.
I
had
I
started
with
the
had
to
be
seven,
and
then
I
went
well.
How
do
I
do
this?
But
to
answer
your
question,
do
I
think
it's?
Of
course
it
can
change.
I
I'm
not
even
100
in
stone
about
the
seven
that
I've
got,
because
I
think
there's
a
and
feel
free
to
comment
back
on
me
right
being
being
very
experienced
in
cloud
native
yourself,
of
course,
that
that
area
between
deployment
and
run
time.
B
B
We
have
the
the
idea
of
pre-flight
checks
to
infrastructure
as
code,
we
have
the
idea
of
monitoring
behavior
at
run
time,
but
these
these
kind
of
oddly
sit
in
the
middle
of
whether
they
are
how
they
are
still
can
be.
They
represent
a
declarative
level
of
security,
but
they
walk.
They
are
that
bridge
between
layers
right
and
I
don't
I
don't
know
if
that's
its
own
layer
in
its
own.
Maybe
it's
like
that's
6.5
or
something
so
someone
might
come
up
with
a
better
way
of
doing
this.
A
Yeah,
I
also
think
one
of
the
the
large
holes
too
is
when
you
get
into
cloud
providers.
They
also
enforce
those
different
layers.
You
know
with
different
means
right,
if
you're
doing
something
like
like
a
cloud
run
or
serverless
versus
a
managed
kubernetes
offering
right
you're
going
to
have
different
different
checks
right
as
part
of
that
pipeline
and
that
build
up
to
actual
run
time.
B
B
B
Well,
I
think
the
common
ground
is
the
application.
I
alluded
roughly
to
that
right.
People
have
been
writing
applications
for
well
what
the
whole
30
years.
Let's
just
say
that
right,
I
started
as
a
developer
in
my
teens
right,
so
I
was
I
was
writing
bad,
insecure
code
from
a
very,
very
young
age
and
the
idea
of
the
idea
of
thankfully
the
idea
of
quality
came
in
first.
That
was
where
I
actually
that's.
Actually,
where
my
my
background
starts.
It
doesn't
start
in
security.
B
It
starts
in
quality
and
craftsmanship
and
things
like
that
right
and
then
that
was
a
natural
mutation
into
security.
But
people
got
that
early,
it's
only
when
we
started
to
move
into
the
idea
that
now
we're-
and
I
think
in
parallel
data
center
security
was
understood,
and
so
I'm
probably
being
generous
there
too
right
speaking
to
some
of
my
data
center
friends,
but
those
came
up
side
by
side
and
very
much
siloed
and
now
we're
at
a
point
where
those
are
let's
say,
merging
into
a
single
entity
of
in
terms
of
security.
B
So,
while
there's
a
common
ground
and
understanding
within
security
teams
that
we
need
to
secure
the
application
and
then
there's
people
in
ops
who
are
starting
to
understand
that
we
need
to
secure
this
cloud
what's
missing,
so
that
those
are
the
common
areas.
What's
missing
is
the
idea
of
how
do
we
bring
out
that
all
together
under
a
single
understanding
or
a
single
effort?
That's
where
the
mystery
lies?
That's
where
the
terminology,
the
new
terminology,
which
we
like
to
poke
holes
in
like
devsecops,
emerges
this
this.
This
unicorn.
A
Yeah
and
cloud,
and
in
general
these
these
new
technologies
have
been
adopted
and
adopted
fairly
quickly
right,
so
do
you
think
that
the
speed
of
adoption
for
new
technologies
also
leads
to
a
massive
challenge
for
upper
management
to
how
to
place
security
teams
like
if
you
have
an
existing
security
team?
You
might
just
say
hey.
You
need
to
go,
learn
this,
instead
of
actually
maybe
re-architecting
your
security
team
into
something
different.
B
B
B
It's
anything
you
buy
as
a
service
is
something
that
is
enabling
you
to
move
quickly
and
that's
why
they're
there,
but
it
doesn't
change
and
in
fact
it's
an
absolute
nightmare
for
security,
because
now
security
was
a
a
game
of
checks
and
balances
there.
You
could
put
gates
in
place
and
you
could
say
what
you
can
and
cannot
do.
But
now,
if
everything's
based
on
velocity
security,
is
going
to
have
to
start
changing
their
entire
perspective
on
what
it
means
to
apply
security
controls.
A
Yeah,
it's
a
tough
balance,
especially
for
for
people
to
to
get
into
right,
because
I
mean
obviously
at
the
end,
computers
deliver
a
service
for
money
right
and
you
could
get
an
application
up
and
running
in
serverless
fairly
quickly
right,
so
you
used
to
have
to
own
infrastructure
and
own
the
security
risk
and
responsibility
associated
with
that
too.
Right
and
now,
I
think,
a
lot
of
it.
A
The
conversation
of
where
the
responsibility
lies
is
also
somewhat
muddled,
because
maybe
you
don't
actually
understand
all
of
the
layers
of
the
cloud
that
maybe
are
supported
versus,
not
supported,
right
and
then
open
source
also
makes
things
somewhat
more
complicated.
Because
then
you
could
have
cloud,
you
can
have
open
source
applications
on
your
platform
and
you
can
have
your
own
application.
B
Okay,
you're
making
reference
to
the
I
so
and
for
for
anyone
who,
if
you
haven't
seen
my
layer,
cake
talk,
you
can
find
it
on
the
open
shift.
Commons
on
youtube
and
you'll
see
the
reference
that
we're
talking
about
noisy
versus
dangerous.
So
I
made
a
reference
that
I
characterized
information,
security
or
those
were
those
people
responsible
for
kubernetes
security.
In
my
talk-
and
I
stated
one
of
the
biggest
problems
they
have
to
deal
with
is
tools
fall
into
tend
to
fall
into
one
of
two
categories.
This
is
a
perception,
not
necessarily
a
reality.
B
I
think
that's
something
I
need
to
make
clear
tools
that
generate
a
lot
of
noise
are
tend
to
be
favorable,
so
if
you
in
the
past,
so
if
you've
got
something,
that's
that's
monitoring,
runtime
or
real-time
activity
within
any
kind
of
application.
We
can
even
go
pre,
kubernetes
or
pre-cloud
and
you're
pushing
that
the
the
tendency
would
be
to
take
everything
all
logs-
all
activity-
kubernetes
logs
linux,
logs
syslog,
everything
punch
that
into
splunk
or
some
or
you
know
some
kind
of
seam
tool.
B
B
So
that's
where
I
think
of
noisy
if
I
were
to
define
a
tool
as
noisy
and
I
don't
want
to
poke
holes
at
noisy
but
having
started
in
static
analysis.
Static
analysis
was
notorious
for
false
positives.
It
was
noisy
and
finding
things
that
mattered
meant
people
didn't
use
it,
because
that
work
was
just
too
hard.
B
I
think
certainly
increasing
cloud
security.
When
you
talk
about
what
we're
trying
to
do
in
terms
of
characterizing,
what
good
versus
bad
behavior
looks
like
both
for
workloads
and
what
they're
doing
we
can.
We
can
do
better
in
a
microservice
environment,
because
by
definition,
containers
are
meant
to
be
simpler.
So
that's
good,
so
we
should
be
less
noisy,
but
I'm
not
convinced
that
right
now
we
are
all
the
time,
because
we
often
as
security
tools
don't
design
ours.
B
We
we
maybe
have
a
fallback
position
of
oh
just,
send
it
to
splunk
or
just
send
it
to
elasticsearch
or
just
send
it
to
whatever
it'll
be,
and
let
let
that
expert
sort
it
out
who
doesn't
even
really
understand
the
data.
That's
arriving
right,
that's
the
bad
thing
about
noisy
the
bat.
The
the
flip
side
of
that
is
what's
a
dangerous
perception
is
that
someone
comes
in
and
is
aware
of
the
noise
right,
so
they're
saying
our
tool.
Our
tool
is
way
better.
B
We're
only
going
to
tell
you
when
this
really
really
important
thing
happens
and
as
much
as
that
is
just
this
sweet
sound
to
a
security
person
who
has
epic
tool
fatigue,
there's
like
a
little
kind
of
devil
on
the
shoulder
saying.
Can
you
trust
them?
I've
been
brought
up
on
zero
trust.
How
do
I
trust
this
security
vendor
to
know?
What
is
it?
What
is
their
methods?
How
what
is
their
technique,
how
they
defined
risk?
Do
they
understand
my
risk?
Do
they
understand
my
compliance?
B
Do
they
understand
my
the
board
members
who
want
me
to
go
up
and
report
about
to
prove
that
this
silence
is
good,
so
that's
what
they
gets
perceived
as
dangerous
and
that
that
the
tooling
involved
could
be
amazing.
It
could
actually
be
doing
what
they
say.
It's
doing
that
doesn't
change
the
perception
as
security
people
that
what
if
I
missed
something?
B
What
if
I
only
had
that
signal
and
yet
something
else
happened,
and
I
had
no
signal
now-
I
don't
have
the
data
or
do
I
have
the
data?
Is
it
somewhere
else?
Can
I
go
get
it
can
I
can?
I
still
run
my
forensics
to
know
how
to
learn
post,
breach
or
post
event.
So
that's
where
that's:
where
danger
comes
into
play
and
that's
that's
that
eternal
struggle
with
within
tooling
is
I'm
finding
that
middle
ground?
That
signal
to
noise
ratio
is
a
a
sweet
spot.
That
is
pretty
elusive.
A
Yeah
and
we've
also
made
it
somewhat
more
complicated
with
microservices,
where
you
know
your
call
stack
comes
in
out
of
order
too
right.
So
how
do
you
also
triage
and
organize
and
honestly,
like
you,
have
auto
healing
right,
so
you
could
have
somebody
some
sort
of
malicious
attacker
right.
How
do
you
go
about
solving
for
something
like
that?
That's
a
tough!
It's
a
tough
thing
to
solve!
For
it's,
it's
a
it's
a
suit!
Okay!
So
go
ahead!
Go
ahead!
B
B
B
A
Yeah
and
actually
your
brain's
going,
I
could
see
you
yeah,
I'm
thinking
about
it
yeah.
It
actually
leads
into
the
next
question.
To
a
certain
extent,
though,
it
was
more
around,
you
know,
reactive
versus
proactive
security
tools.
Right
so,
like
you
said,
you're
collecting
all
this
information
again
you're
using
all
that
information
to
then
react
to
some
sort
of
threat
or
or
hack
that
comes
through
later
on
right.
So
how
much
do
you
balance
the
two?
A
B
Yeah,
it
was
kind
of
well
you,
you
you're
doing
a
fine.
It's
a
fine
way
of
saying
that
that
was
the
premise
behind
the
layer.
Cake
idea
is
that
you're
building
something
from
the
bottom
up
security
shouldn't
be
just
the
icing
right.
Although
I
love
icing
right
we're
getting
to
the
cake
analogy,
you
should
have
your
buttery
biscuit
base
which
you're
putting
down
there
and
it's
super
secure,
because
building
on
top
of
it
means
well
everything
you
build
on
top
of
a
bad
base,
be
it
cake
or
be
it
housing
or
being
whatever
it
is.
B
You're
building
isn't
ideal
and
security
should
be
a
part
of
that.
The
more
you
do
in
the
various
stages
in
terms
of
checking
static
analysis
tools,
just
looking
for
oauth
10
type
vulnerabilities
looking
at
dependencies
for
known
vulnerabilities,
even
if
you
can't
contextualize
them
yet
you
know
just
knowing
you
have
that
in
your
backlog
is,
is
easy
and
effective
and
then
moving
that
into
the
image
and
then
providing
context
by
checking
things
like
gamma
or
helm
charts
to
see.
Am
I
pushing
all
of
that
data?
B
I
acquired
on
my
way
here
into
something
that
is
a
potentially
dangerous
scenario.
So
am
I
increasing
the
likelihood
of
risk
essentially,
which
we
haven't
defined
like
risk
is
most
people
know
risk
is
impact
times
likelihood,
that's
the
simplified
definition
of
it
and
any
any
anything
we
can
do
to
reduce.
That
is
good,
so
we're
talking
about
likelihood
when
we
start
getting
without
data-driven
decisions
on
likelihood
we're
not
we're
just
kind
of
putting
our
finger
in
the
air.
So
all
that
information
we
get
on
the
layers
is
all
great.
B
B
B
If
I
can
start
adjusting
my
runtime
controls
based
on
knowledge,
I
acquired
on
the
way
there
throughout
the
various
layers.
That
means
my
runtime
gets
into
this
nirvana
state
that
you're
talking
about
of
just
being
quiet,
because
I've
turned
the
volume
down
where
it
doesn't
matter,
and
I
can
turn
the
volume
up
where
it
does,
and
I
can
turn
it
up,
because
those
are
the
vulnerabilities
I
have
addressed.
B
A
Yeah,
you
and
larry,
I
think,
are
thinking
along
the
same
wavelength.
Both
said
you
know,
good
security
is
noisy,
but
the
reporting
is
quiet
right
and
I
think
the
the
tough
thing
obviously
is
normally.
When
you
get
these
tools
out
of
the
box,
they
make
everything
extremely
noisy
right,
because
at
the
end
of
the
day,
it
is
up
to
you
and
your
security
team
to
adjust
those
those,
the
dials
and
the
knobs
right.
A
One
of
the
things
that
I
find
as
a
challenge
is
taking
like
what
you
said
about
risk,
or
you
know,
noisiness
and
alerting,
and
then
adapting
that
to
the
container
centric
focus
right,
because
you
do
have
these
larger
tools.
And
now
it's
hey.
We,
you
know
we
did
security
this
way
and
we're
trying
to
shift
it
towards
containers.
B
How
do
I
manage
risk
in
a
container-centric
world?
That's
coming
back
to!
Oh
all,
right!
I'm
gonna,
like
pick
on
you
a
little
bit
for
calling
it
container-centric
world,
maybe
because
I
think
right
away.
We
shouldn't
be
looking
necessarily
at
risk
associated
with
the
container,
because
I
can
run
and
we've
had
this
conversation
before
like
a
good
practice
would
be.
I
can
run
a
container
using
docker
compose,
it
comes
up
and
it
behaves,
and
then
I
can
push
that
into
test.
I
can
push
it
into
pre-prod.
B
I
can
go
into
prod
and
that's
all
great
right
and
that
container
could
have
a
variety
of
indicators
of
risk
from
poor
exposures
to
vulnerabilities
to
application
vulnerabilities.
I
could
have
all
sorts
of
things,
but
the
context
of
putting
it
on
my
desktop
renders
it
zero
likelihood
of
breach
zero
impact.
That's
on
my
desktop,
so
risk
doesn't
exist
in
that
container's
context.
B
So,
but
it's
what
it's
that
containers
journey
and
where
it's
going
to
end
up,
be
it
an
internal
accounting
system
or
be
that
the
front-end
identity
management
system
for
my
e-commerce
shop
then
suddenly
the
further
it
gets
towards
its
deployment
context.
Its
risk
its
likelihood
and
certainly
its
impact
goes
up,
for
example,
if
this
is
the.
If
this
is
a
container
that
manages
access
to
a
database,
then
its
environment
variables
might
have
sensitive
information
to
allow
me
to
access
that
database.
Okay,
so
that's
fine
everywhere.
It
exists
outside
of
production.
B
Who
cares
with
the
exception
of
insider
threat,
of
course,
but
once
it
goes
into
prod,
then
you
start
looking
at.
What's
the
journey
to
get
access
to
that
information,
it
can
I
get
access
directly,
no
okay.
Well,
then
likely
it
goes
down.
Can
I
get
do
I
have
network
policies
in
place
that
should
I
get
access
to
one
of
the
front
end
containers?
B
Can
I
jump
directly
to
that?
Okay?
Well,
I
can,
and
that
likelihood
is
high.
I
need
network
policies
to
prevent
that
such
that
there's
an
elaborate
lateral
movement
that
needs
to
happen
to
reach
there
and
then
likelihood
goes
way
down
or
I
have
to
pop
out
of
some
root
container
and
dig
a
hole
underground
through
the
node
and
pop
up
that
way.
I've
got
bigger
problems
than
that
database.
If
that's
the
the
root
in
right.
B
So
it's
it's
that's
the
way
we
start
looking
at
what
what
represents
risk
in
a
containerized
environment,
it's
what's
happening
all
around
it
and
that's
when
you
start
looking
at
just
looking
at
containers
alone,
looking
at
images
alone,
looking
at
scanning
alone,
any
of
these
methods
in
isolation
can
just
prove
to
be
theater
as
opposed
to
an
actual
real
definition
of
risk.
Well,
that
was
a
long
answer.
Was
that
all
right.
A
Yeah,
no,
I
mean,
I
think
you
summarized
it
very
fairly
succinctly
for
a
complex
topic.
I'll
say
that,
because
again
like
I
mean
containers
really
that
I
do
empathize
with
people
who
you
know
buy
into
virtual
machines
to
a
certain
extent,
because
it's
the
way
that
we've
been
doing
it.
There
is
a
lot
of
sort
of
better
capsulation
of
all
the
information.
That's
going
on
behavior
within
the
virtual
machine
right,
so
containers
really
shifted
that
and
then,
like
you
said,
you
know,
you
have
a
database.
A
Let's
say
container,
you
know:
are
you
injecting
the
secrets
instead
of
actually
building
them
into
the
docker
files?
Because
you
really
shouldn't
be
in
the
talker
files
right,
there's
so
many,
but
but
then
again,
let's
say
you're
starting
off.
That
might
be
the
quickest
way
to
do
it
because
you
can't
set
up
vault
or
something
like
that
right.
A
B
Well,
you
just
use
the
word
anti-pattern.
I
think
that's
a
that's
it's
funny.
We
call
anti-patterns
right,
but
when
we
look
at
new
organizations,
anti-patterns
are
the
patterns
and
and
they're
they're
actually
working
towards
like
what
is
considered
a
best
practice
pattern.
But
it's
amazing
how
so
many
of
these
things
we
could
we
criticize,
as
anti-patterns,
are
just
what
everyone
does
at
the
start.
A
Yeah
and
the
other
thing
too,
is
as
a
security
tool
or
security
team.
How
much
do
you
allow
that
to
to
move
forward
right?
This
is
just
more
of
a
cultural
concept
of
you
know
your
security
team
and,
at
the
same
time
you
don't
want
to
hamper
development
and
containers.
Allow
you
to
develop
a
lot
faster.
So
how
much
do
you
allow
those
patterns
to
move
forward
without
saying
hey?
No,
we
need
to
actually
completely
shift
this
right.
A
That
friction
is
obviously
just
always
going
to
be
there,
and
I
think
it's
like
led
to
that
conversation
of
devsecops,
although
partially
maybe
misused
yeah.
So
we
talked
about
a
little
bit
about
the
communication
between
humans
and
that
friction
in
terms
of
context
when
creating
security
security
tools.
Right
so
let's
say
you
have
a
kubernetes
security
tool.
You
have
a
vm
security
tool.
A
Do
you
think
it's
better
to
have
a
single
tool
that
manages
both
or
do
you
have
two
separate
tools
with
maybe
some
sort
of
collector
we've
talked
a
lot
about
the
context
with
containers
in
the
context
of
the
with
vm.
So
I
just
want
to
get
your
opinion
on
what
situation
works
better
and
how
do
you
kind
of
alleviate
that
friction
between
teams
right,
because
we
almost
are
getting
to
the
point
with
the
cncf,
where
it's
a
tool
for
a
specific
purpose
right,
so
there
needs
to
be.
A
B
The
single
oh
yeah,
so
I
I
I
once
I
was
at
a
talk
when
I
was
traveling
around
scandinavia
and
there
was
a
a
guy
who
came
on
just
before
me.
Shy
name
and
shame.
Should
I
do
that
he
was
from
microsoft.
I'll
just
say
that,
but
he
was
really
nervous
and
he
was
talking
about
their
new
great
thing.
I
think
it
might
have
been
arc,
but
it
was
and
he
slipped
up-
and
he
said,
a
single
glass
of
pain.
B
He
meant
to
say
single
pane
of
glass
and
I
laughed
so
loud.
It
wasn't
like
it
was
it
disturbed
the
room
because
he
was
right
and
I
might
this.
I
made
a
slide
immediately
afterwards
that
had
like
a
glass
of
coarse
light.
As
my
image
for
the
single
glass
of
pain,
it
was,
and
it
was
great
because
that
he
was
sort
of
correct
in
what
he
said-
security
people
like
the
idea
or
the.
B
But
that's,
it
doesn't
really
exist
and
I
think
there's
a
hybrid
approach
where
that
probably
works
in
a
reality
a
little
bit
better,
because
if
there's,
if
there's
a
way
of
utilizing
information
I'll
give
you
the
like
they'll,
go
back
to
the
layers
idea
right.
If
I
have
image
vulnerabilities
awesome,
but
if
I'm
scanning
or
running
preflight
checks
on
deployment.
B
Well,
it's
to
my
it's
in
my
interest
to
know
the
image
vulnerabilities,
not
just
the
misconfigurations,
by
not
having
security
context.
It
makes
more
sense
that
I
can
see,
there's
a
service
and
there's
a
load
balancer
and
it's
it's
referencing.
This
application
for
this
metadata
and
it's
running
this
engine
x,
115,
which
is
like
way
too
old
and
has
all
these
vulnerabilities-
and
I
know
the
vulnerabilities
so
now
I
actually
am
putting
image
vulnerabilities
into
context
of
deployment,
that's
really
powerful
and
that
needs
that
should
be
under
a
single
tooling
example.
B
That
doesn't
mean
that
the
industry's
not
answering
that
that
cry
for
the
single
pane
of
glass.
If
you
look
at
the
we
talk
about
this
all
the
time,
we
monitor
acquisitions-
and
you
see
the
consolidation
of
the
tooling
market,
already
happening
with
big
players,
swallowing
up
little
players
with
this
idea
of
bringing
them
all
together
into
some
like
platform
and
yet
then
struggling
to
present.
What
that
platform
really
means.
I
mean
in
my
previous
life
at
synopsis.
They
did
that
that
they
were
an
acquisition
machine.
B
A
Yeah,
there's
there's
a
couple
other
issues
too,
with
consolidation
as
well
as
like
picking
single,
you
know,
applications,
especially
with
the
cncf.
You
know.
Sometimes
it's
a
little
bit
developer
driven
right,
so
you
get
projects
that
were
hot
three
four
years
ago
that
aren't
necessarily
in
the
same
position.
They
are
nowadays
right
just
kind
of
a
general
question
towards
you
know
those
you
know.
Small
tools.
B
Well,
I
think
yeah.
I
guess
there
can
be
silos,
but
it's
not
like
tools
create
silos.
If
you
got
that
the
silos
probably
already
exist
in
your
organization
and
that's
why
the
poll
methodology
of
adopting
tools
which
is
sort
of
the
developer
preference?
That's
what
happens.
I
mean
I
I've
been
on
the
the
dark
side
of
the
the
vendor
side
of
selling
tools,
where
you
engage
with
a
security
team,
for
example,
and
they
say
we
love
it
and
then
they
buy
this
thing
from
your
organization.
B
Doesn't
matter
what
it
is
you
return
in
six
months
and
actually
the
purchase
of
said
tool,
be
it
doesn't
matter
what
a
static
analysis
to
a
kubernetes
cloud
native
security
solution.
All
that
did
was
wake
the
developers
up
to
the
fact
that
oh,
we
need
something
like
this,
and
these
guys
want
us
to
do
this.
It's
not
like
developers
aren't
curious
about
security.
B
They
just
weren't
involved
in
the
conversation.
So
now
they
are
you've
already
bought
it.
So
they're
going
to
go,
do
their
own
homework
and
it
won't
take
very
long
before
they
found
that
an
easily
pullable
integratable
solution
existed
in
open
source
and
they're,
going
to
start
using
it
and
now
you've
actually
created
an
internal
silo.
The
competition
between
security
and
developers,
because
the
developers
have
decided
open
source
x
is
what
they
really
want
to
use
and
they
don't
want
to
use
that
thing
you
bought,
so
it
exacerbates
an
existing
silo.
It
can
do.
A
B
B
Now,
that's
fine,
I
totally
think
that's
the
case.
I
think
when
people
say
some
people
have
argued
that
the
phrase
devsecops
is
just
a
shoehorn.
It's
devops.
If
you
look
at
various
definitions
of
devops,
some,
I
think
was
the
microsoft.
One
actually
says
security
is
part
of
this.
It's
it's
the
integration
of
of
everything
to
make
sure
that
it
runs
for
a
specific
purpose
and
security
is,
is
accounted
for.
The
only
reason
it
isn't
or
often
isn't.
B
I
should
say
it's
just
culture
and
education,
you
know
and
and
and
to
an
extent
incentive,
because
we
don't
really,
I
mean
in
the
organizations
I've
worked
for
where
I
have
the
privilege
of
talking
to
development
organizations,
and
I
say
well
what
what
is
it?
What
are
your
incentives?
What
is
your,
what
are
your
team
and
they
say?
Oh
well,
we
our
incentives,
are
to
reduce
our
build
time
to
15
seconds.
B
You
know
like
all
right,
so
there's
nev,
very
rarely,
a
mission
of
of
making
sure
our
team
produces
the
most
secure
code
when
it
gets
to
the
point
where
that
those
checks
come
into
play
like
there's.
No,
there
isn't
a
there.
Wasn't
reward
or
there's
no
carrot
around
that
so
once
we
start
to
educate
around
that
and
provide
that
as
part
of
the
culture-
and
I
think
you
know
university
and
the
way
we
train
at
the
moment
needs
to
be
a
part
of
that.
B
Then
it'll
just
happen
and
some
of
these
problems
we're
talking
about
of
having
silent
security
or
out
of
band
or
all
of
the
all
the
measures
that
security
teams
have
to
do
at
the
moment
to
try
and
tiptoe
around
this
velocity
model,
hopefully
will
get
baked
in
a
lot
easier,
see
it
baked
in.
I
got
it
back
to
cake.
A
A
B
B
The
first
step
of
friction,
which
is
what
people
don't
think
about,
is
financial.
It's
budget
people
probably
expecting
to
say:
oh
developers
won't
want
it,
and
I
think
you
actually
have
an
easier
time.
If
you
go
to
developers
who
love
cloud
native
and
love
kubernetes-
and
you
say
I
bought
a
tailored
kubernetes
security
solution
as
a
security
person-
oh
my
goodness,
they'd
be
like
oh,
this
is
you're
amazing
you're,
actually
providing
a
security
in
a
language
we
like.
B
So
I
think
you'd
do
better
there
than
you
would
most
security
teams
would
do,
but
where
you're
gonna
find
resistance
from
the
outset
is
when
you
say
when
you
turn
to
the
cfo
and
say
yeah,
but
it
costs
x
and
they
go
didn't.
We
just
buy
the
vm
security
solution
like
last
year
that
costs
us
this.
Our
entire
budget,
like
how
do
I
justify
this
new
budget?
For
this
new
thing,
when
I
have
the
budget
already
being
spent
on
the
other
thing,
the
old
thing
we
still
have
legacy
systems
so
prove
to
me.
B
I
need
this
new
thing,
so
that's
that
I
think,
is
like
the
very
very
first
step
of
friction
when
you're
trying
to
go
cloud
native
security
like
unless
you're
cloud.
First,
in
which
case
great
your
budget
for
security,
is
you
didn't,
have
any
legacy
security
tools
or
incumbent
things
that
are
legacy
taking
your
budget
away,
but
if
you're
talking
enterprise
you're,
probably
not
brand
new
right
you're
like
a
financial
institution
or
something
this
is
a
struggle.
A
A
B
So
the
next
level
friction
is
scale,
the
more
touch
point.
The
more
people
have
to
be
involved
in
your
security
solution,
the
less
likely
it
is
to
succeed
and
then,
beyond
that,
the
more
actual
engagement,
let's
say,
adoption
like
must
have
adoption.
You
need
even
less
likely
that
it
will
succeed.
So
this
is
why
going
back
to
the
static
analysis
analogy,
if
you
expect
everyone
to
use
a
static
analysis
tool,
and
actually,
if
you
require
it,
probably
never
work,
it
almost
has
to
be
optional.
B
But
then
you
need
a
compensating
control
later
on
to
make
up
for
the
fact
that
some
people
didn't
do
it.
So
we're
going
to
check
that
out
of
band,
perhaps
in
ci,
but
the
people
who
embedded
it
into
their
ide.
Well,
they
have
massively
changed
your
risk
posture,
so
that's
great,
but
it
shouldn't
be
required.
B
A
great
example
of
this,
where
it
never
works,
and
we
we
talked
about
a
little
bit
about
this
at
our
meetup
last
week-
is
a
supply
chain
for
tools
like
in
toto
or
some
of
the
new
ones
that
are
coming
along
right
in
order
for
that
to
actually
work.
Every
single
developer
has
to
use
it
for
every
touch
point
on
the
software,
thus
making
it
almost
an
impossible
tool
at
scale
to
prevent
breaches
of
that
style.
So
that's
your
next.
B
Your
next
level
is,
can
I
scale
this
in
a
frictionless
way
in
some
way
and
then
expand
it
and
take
additional
advantage
as
developers
create
additional
touch
points
with
my
security
solution?
If
you
can
do
that,
and
you
have
a
model
for
scaling
your
security
that
adheres
and
acknowledges
that
then
you're
off
to
a
flying
start.
That's
really
good.
A
Yeah
and
I
obviously
that
seems
to
be
sort
of
the
push
for
that
shift
left
right,
but
but
really
what
we're
talking
about
is
security
checks
closer
to
the
developer
as
part
of
the
build
or
deploy
pipeline
right?
If
you
can
do
that,
an
automated
way,
with
maybe
more
of
a
focus
on
engagement
and
knowledge
transfer
as
to
why
the
check's
happening
instead
of
just
like
hey,
you're,
bad,
stop
it
right.
B
A
Oh
sorry,
I
think
I
think
my
internet's
going
very
poorly
today,
but
yeah.
I
know
I
think
once
you
get
to
that
point.
It
really
smooths
a
lot
of
things,
but
that's
really
only
been
available
as
an
option
because
of
this
supply
chain
that
we've
that
a
lot
of
companies
have
set
up
and
also
the
declarative
nature
of
a
lot
of
code
nowadays
right
with
version
control
systems
and
ci
pipelines
without
those
original
technologies.
You
wouldn't
really
have
that
capability.
A
B
Yeah,
I'm
a
huge
fan
of
the
declarative
nature
of
code.
I
find
it
funny
that
it's
a
that
it
took
us
so
long
to
get
there.
I
mean
when
I
I
used
to
write
perl
scripts
when
I
worked
at
nortel
yeah
that
debt
company
that
was
designed
to
do
what
we
are
trying
to
do
now.
Infrastructure
is
code,
but
perl
script
is
a
is
a
logical
coding
language.
It's
not
a
declarative
language.
B
Whether
we're
talking
terraform
that
allow
you
to
say
this
is
my
defined
state
and
then
I
allow
something
else
that
implements
logic
just
to
maintain
that
state
for
me
or
establish
that
state
and
thus
allowing
me
to
check
that
state
in
advance
like
this
is
a
huge
leap
that
we're
all
adopting
this
this
sort
of
method
of
thinking,
but
I
I
feel
like
and
feel
free
to
debate
me
I'd
love
to
get.
Somebody
on
my
podcast
debating
me
about
this.
B
The
idea
that
we
get
really
excited
about
get
offs
like
the
idea
that
now
I've
got
my
infrastructure
of
code
and
I
change
the
code
and
it
automatically
gets
deployed
and
state
is
maintained
by
get
and
change,
control
and
observability
and
a
single
source
of
truth
is
great.
But
if
you
translate
that
back
to
just
application
code,
that's
what
we've
been
doing
the
whole
time.
B
B
I
should
be
if
I
bring
up
yaml
in
my
in
my
vs
code.
There
should
be
something
telling
me
that
I've
I've
missed
my
security
context.
I
don't
even
have
it
in
here.
Something
should
be
telling
me
a
little
squiggly
red
line.
To
be
say,
hey
you
haven't
got
this
here
at
all
or
all
the
same
checks
that
I
would
expect
to
identify.
The
potential
for
sql
injection
in
my
application
code
should
be
doing
the
exact
same
thing
when
I'm
looking
at
helm
or
yaml
or
anything
all
of
this
world
should
happen.
A
Yeah
and
I
think,
as
you
know,
we
get
those
noisy
applications
and
we
get
more
into
the
the
ml
world
right,
like
once.
People
have
had
to
find
kubernetes
applications
for
a
year
or
two
or
three
years
in
your
version,
control
you're
going
to
have
some
sort
of
defined
configuration
as
well
right,
and
so
then
you
can
start
to
look
at
baselining
against
your
actual
declarative
state
right.
So
somebody
goes
in
and
maybe
messes
around
in
github
and
changes
some
sort
of
port
right
on
your
in
your
yaml
files.
A
You'll
automatically
be
notified
of
something
like
that
right
because
you
do
have
this
baseline
structure,
so
I
think
that's
more
of
the
maturity
model
around.
You
know
that
sort
of
declarative
code.
That's
come
up
really
at
the
end.
I
just
I,
I
sort
of
think
it's
just
getting
more
into
observable.
I
I
use
observa
observability
a
lot
because
it's
always
used
in
monitoring,
but
really
I
just.
I
think
it
applies
so
much
more
to
security
to
a
certain
extent
right.
B
B
Oh
yeah
yeah,
that's
perfect,
because
if
you
were
to
look
at
raw
ebpf
output
like
that's,
that's
a
mess
right,
that's
noise,
but
it's
it's!
How
a
security
tool
translates
that
into
actionable
data?
That
is
the
reporting
element
that
is
really
critical,
and
I
think
this
understanding
of
declarative
information.
If
we
bring
all
that
in
and
we
factor
all
that
into
what
is
turned
into
actionable
information,
then
our
observability
is
it's
proper.
It's
we're
not
just
saying
observability
via
opening
the
floodgates
for
for
everything.
Observability
is
not
looking
at
your
ebpf
output.
A
Yeah-
and
I
I
guess
one
of
the
things
I
grapple
with
daily-
is
because
you're
pulling
and
extracting
so
much
information
and
also
doing
basically
a
lot
of
formatting.
You
also
have
to
make
sure
that
the
team-
that's
developing
the
tool,
also
knows
what
they're
talking
about
too
right.
If
you
have
somebody
that
has
a
specific
mindset
for
a
specific
output,
they
might
not
understand
the
final
phasor.
You
might
actually
get
something
lost
in
translation.
A
It's
also
about
basically
the
etl
process
of
how
that
security,
specific
context,
information
gets
to
your
doorstep
right.
Is
it
raw?
Can
I
filter
through
it?
Do
I
have
that
capability,
or
is
somebody
doing
that
for
me
right?
Those
are
the.
I
I'm
not
sure
if
you
had
this
built
into
your
layer,
but
I
I
think
the
the
sort
of
transition
of
information
towards
the
end
user
also
matters
a
lot.
B
B
It
needs
to
be
relevant,
for
the
information
needs
to
be
relevant
for
the
end
user,
and
if
you,
if
you're
talking
about
dev
centric
shift
left
and
the
reality,
is
runtime
information,
a
lot
of
it
is
relevant
for
all
the
way
back
to
the
beginning.
The
shift
left,
so
you
want
them
to
work,
shift
left
they'll
do
as
much
as
they
can,
but
there's
some
something
is
now
something
has
changed.
You
have
a
deployment,
there's
a
new
vulnerability
and
it's
in
my
deployment,
which
means
it's
an
image
that
my
development
team
is
responsible
for.
B
B
It
speaks
the
language
and
the
tooling
that
the
developers
require
and
that's
a
real
struggle
for
tools
to
make
sure
that
they
that
the
tooled
vendor
understands
where
what's
the
destination
for
this
information
who's
it
for
in
the
first
place,
and
let
me
deliver
it
in
a
way
that
speaks
their
language.
That's
a
real
struggle!
Yeah!
If
that's,
where
you're
going.
A
Yeah
and
I
I
think
that
as
much
as
things
become
standardized
or
let's
say
their
outputs
become
standardized
like
yaml
or
json,
there's
still
a
bunch
of
different
ways
that
people
actually
consume
that
information
right
with
so
many
different
contexts.
So
I
you
know
when
you're
talking
about
stakeholders
or
who's
actually
getting
the
output.
A
I
think
you
know
that
is
kind
of
the
core,
the
core
concept,
especially
with
honestly
a
lot
of
applications
right
in
the
end,
it's
business
value
and
I
need
to
sort
of
convey
the
security
state
of
my
solution
or
your
basically
system
through
my
solution
to
you
in
the
best
way
possible
right
and
yeah.
It's
just
because
there's
so
many
different
options-
and
you
know
you
have
different
clouds.
Different
providers,
kubernetes
vms,
bare
metal
right
bare
metal,
has
become
a
an
interesting
conversation,
the
last
five
years.
A
You
know.
I
I
think
that
the
the
context
matters
so
much
because
to
be
honest,
security
and
tools
move
so
fast.
I
actually
think
that's
where
you
see
most
roi.
Most
of
your
return
is
because
you
can
implement
a
security
solution,
doesn't
necessarily
mean
that
you're
going
to
get
the
most
bang
for
your
buck
out
of
it
right.
If
one
you
don't
have
an
option
or
two
you're,
actually
not
even
getting
the
right
context
right.
A
A
B
Doing
interested
in
watching
I'll
make
one
comment
we
didn't
really
touch
on
which
I
think
was.
It
was
a
something
that
really
stuck
for
me
with
our
conversations
we've
had
with
jessica
cherry
was
she's,
got
a
bug,
bear
about
tribal
knowledge
and
something
I
probably
should
have
mentioned.
That
is
a
real
plus
of
a
declarative
nature.
Both
security,
but
just
anything
ops,
is
that
if
you've
got
a
tool
that,
if
you
recognize
that
this
tool
will
eliminate
tribal
knowledge
of
my
organization
or
this
method
or
this
language,
that's
probably
good.
B
That's
going
to
save
you
money
right
away!
So
that's
if
you're
looking
for
where
to
start.
That's
a
great
question
to
start
asking
yourself:
how
can
I
eliminate
tribal
knowledge?
Well,
if
this
tool
that
analyzes
terraform
is
going
to
make
sure
that
everybody
uses
terraform
and
it's
going
to
check
and
it's
going
to
ensure
that
it's
all
correct
and
we
get
down
that
path,
and
therefore
I
don't
have
one
person
who
knows
how
to
set
my
cloud
amazing.
Do
that!
So
that's!
A
Nice
awesome,
yeah,
jessica,
cherry
and
she's
part
of
the
meetups
as
well,
really
a
big
fan
of
breaking
clusters,
so
yeah
check
her
out.
She
does
some
good
chaos,
engineering
work,
so
cool.
We
have
no
questions
in
the
chat
for
you
thanks
again
for
joining
anybody
else.
That's
watching
steve
anybody!
Anybody
else,
that's
watching
the
recordings
will
be
sent
out
after
if
you
missed
anything,
feel
free
to
share
and
thanks
again
for
joining,
take
care
and
have
a
good
friday
and
rest
your
weekend.