►
Description
Ali Golshan joins Alan Shimel, editor-in-chief of DevOps.com for a chat about what it means to be a Kubernetes-native security platform and why we believe it’s the most effective way to secure containers and Kubernetes.
A
This
is
digital
anarchist,
hey
everyone,
its
Alan
shovel,
editor-in-chief
of
DevOps,
calm
security,
Boulevard
and
we're
coming
at
you
today
on
our
digital
anarchists
platform,
happy
to
have
sort
of
a
surprise.
Video
interview
with
a
friend
of
mine,
I'd
like
to
introduce
you
all
to
a
league
ocean
whose
CTO
gulshat
who's,
the
CTO
of
stack
rock
stack,
rocks
st
ack
ro
ex
ally.
Did
I
get
that
right?
A
You
did
yeah!
Thank
you.
Thank
you!
So
Ali
we're
gonna,
we're
gonna,
spend
the
next
20-30
minutes
talking
about
kubernetes
containers
and
security,
but
before
we
do,
I
just
wanted
to
get
out
of
the
way.
Maybe
there's
some
people
in
the
audience
who
are
not
familiar
with
stack
rocks.
So,
let's
take
a
minute
or
two
and
kind
of
put
that
to
rest
who
is
stack,
rocks?
What
do
you
guys
do
and
we'll
go
from
there
sure.
B
So
stack
works
was
founded
in
January
2015.
Our
main
mission
has
been
to
build
safety
for
developers
and
security,
tooling
for
security
engineers
and
operators,
with
a
specific
focus
on
kubernetes
native
control,
securing
containers
and
micro
services
on
top
of
it.
So
rather
than
looking
at
the
world
through
their
lowest
common
denominator,
which
is
you
know,
containers
on
top
of
any
Orchestrator,
we
decided
to
double
down
and
take
a
look
at
and
say.
B
A
Well,
that
was
a
good
bed
in
hindsight
right
and
this
is
why
I'm
much
better
bedding
in
hindsight
than
thinking
bets
beforehand,
but
you
picked
the
right
one,
but
but
seriously
when
we
look
at
kubernetes.
You
know:
I
just
had
this
discussion
earlier
today
with
someone
I
was
trying
to
they
ask
me
what
is
Cooper
daddies
and
why
is
it
important
and
I
tried
to
explain
to
them?
A
You
know
VMware
spent
about
5
billion
dollars
last
week,
right
on
some
acquisitions
and
so
much
of
what
they've
spent
in
so
much
of
the
VM
world
buzz
coming
out
has
been
they're
sort
of
moved
towards
DevOps
and
kubernetes
been
right
and
and
and
when
we
look
at
it,
you
know
what
powered
the
cloud
for
the
last
15
years.
Let's
call
it
right,
it
was
the
hypervisor
and
and
how
quick?
A
If
you
would
have
told
me
like
this,
you
know
the
snap
of
a
finger,
it's
sort
of
a
foul,
no
snap
from
the
Avengers
right,
we're
gonna
kind
of
change,
the
course
of
history,
and
it's
not
the
hypervisor
that
is
dominant.
It's
the
container
in
the
container
Orchestrator
that
becomes
the
dominant
infrastructure
in
in
in
the
cloud
I
would
have
said,
you're
crazy
right
this
ends.
A
B
So
I
think
a
good
way
to
think
about.
It
is
maybe
taking
a
step
back,
and
you
mentioned
this
virtualization
was
really
what
triggered
this
entire
cloud
movement
and
I.
Think
if
you
look
at
until
you
know
a
few
years
ago,
kind
of
called
it
2013
2014
majority
of
the
drive
around
containerization,
coop,
virtualization
and
cloud
was
still
very
much
focused
around
monolithic
applications,
and
what
I
mean
by
that
is,
is
that
you
either
wanted
to
run
that
monolith
on
Prem.
B
B
They
all
float
out
to
the
public
cloud.
What
has
really
driven
this
now
has
been
this
pushed
towards
microservices,
so
kubernetes
is
emergence,
has
really
been
due
to
the
need
for
building
distributed
systems
that
are
high
availability,
high
performance,
highly
scalable
and
automated,
and
this
was
a
big
realization,
where
initially
I
think
the
move
to
containerization
should
be
really
separated
from
move
to
kubernetes.
B
What
I
mean
by
that
is,
if
you
look
at
it
four
five
years
ago,
developers
starting
to
use,
containers
and
I'm
a
big
believer
that
everything
in
user
space
will
eventually
run
in
some
isolated
formats.
So
containers
happens
to
be
the
current
form
factor,
but
containers
are
a
decision
that
developers
or
DevOps
or
engineers
generally
made
as
a
tool
to
use.
B
If
you
think
about
kubernetes
kubernetes
is
essentially
a
business
decision,
you
make
it
as
part
of
your
business
or
judo
transformation,
because
it's
a
huge
bet,
you're
making
and
the
reason
for
this
is
it
affects
your
developers,
your
ops,
all
the
way
through
your
security
folks.
So
what
we
are
seeing
is
really
twofold:
we're
seeing
a
large
class
of
companies.
B
So
what
I
will
say
is
is
the
adoption
of
kubernetes
is,
as
is
as
high
velocity
as
containers,
but
the
day-to-day
impact
of
it
you're
starting
to
now
just
see
it
is
because
people
initially
build
containers
and
then
once
that
got
says
sort
of
a
density
level.
Now
they
looked
at
and
they
said
oh
holy
crap.
How
do
we
actually
manage
and
orchestrate
and
move
all
these
things
around
and
that's
where
kubernetes
came
a
little
bit
later?
A
couple
of
years
after
the
initial
containerization
movement.
A
A
We
run
ahead
and
do
this
stuff,
because
there
is
a
good
reason
for
it
and
bring
some
real
benefits
and
then
all
of
a
sudden
someone
says
gee
what
about
security
right
and
and
oh,
oh
yeah,
there's
that
security
thing
again
right
and
we
saw
it
with
the
cloud
we
saw
it
with.
We've
seen
it
at
every
step
of
the
way,
from
decentralized
the
centralized
client-server
inside
job,
endpoints,
mobile
and
and
so
container
security
became
sort
of
a
thing.
A
Let's
say
four
years
ago,
right
five
years
ago,
Thompson
and
again
just
like
I've
seen
another
areas
like
the
the
first
response
was
well
we're
gonna,
take
our
security
that
we
already
have
and
we're
just
gonna
container,
wash
it
or
containerize
it
or
whatever.
You
want
to
use
that
term,
and
so
it
really
wasn't
that
good
I
mean
I'm
trying
to
be
kind,
but
it
stunk
right.
It
was.
It
was
the
wrong
tool.
It
was
the
wrong
tool
for
the
job
and
as
any
man,
hotel,
you're,
right
and
we're
gonna
get
all
manly.
A
B
That's
a
great
point,
so
the
way
I
think
about
it
is
in
the
context
of
crawl,
walk
run
when
you're
talking
about
initially
people
using
containers
using
a
lot
of
traditional,
tooling
and
security.
That
was
the
crawl
stage,
where
I
feel
like
a
lot
of
customers,
were
experimenting
with
containers.
Think
what
does
docker
dudes?
What
does
cryo
do?
What
are
all
these
container
technologies,
enabling
my
developers
to
do
so?
I
think
what
ended
up
happening
is,
especially
if
you
kind
of
rewind
five
years
ago,
those
containers
were
limit
running
in
limited
capacity.
B
Naturally,
people
didn't
want
to
go,
invest
specifically
for
some
low
level
risk
thing
as
security
things
about
and
then
the
second
part
of
it,
which
is
quite
frankly,
my
issue
with
the
larger
security
industry
is
as
soon
as
there's
an
emerging
technology,
insecurity,
majority
of
security,
vendors
just
look
at
it
as
a
marketing
problem,
oh
yeah.
Of
course
we
cover
that.
Oh,
of
course,
our
products
can
secure
that
which,
in
the
case
of
containers
and
specifically
moving
forward
kubernetes
and
micro
services
is
untrue.
B
You
need
an
entirely
different
structure
architecture
because
the
structure
of
running
applications,
immutable
ephemeral,
distributed
and
then
introduction
of
the
entire
DevOps
lifecycle
of
CI
CD
impact
with
that.
So
that's
kinda
I
feel
like
where
we
move
from
crawl
to
walk
where
companies
realize
ok.
Initially,
we
have
some
protection
around
these.
Now
we
realize
traditional
vendors
don't
solve
this.
So
what
is
the
low
head
lowest
hanging
fruit?
B
We
have
to
go
solve
with
touched
vulnerability,
scanning
I'm,
a
huge
advocate,
because
I
think
understanding
what
vulnerability
is
introducing
into
your
environment,
doing
proper
image
scanning,
so
I
understand
packages
and
dependencies
and
license.
This
is
all
very
important
now.
The
problem
here
again
was
that
traditional
models
of
vulnerability
scanning
either
at
runtime,
scanning
or
traditional
static,
did
not
apply
to
this
DevOps
cycle.
So
with
containers
then
came
the
acceleration
of
CI
CD
tooling,
and
a
DevOps
workflow
so
being
able
to
have
vulnerability
scanners
that
integrate
into
my
CI
CD
into
my
registry.
B
Scan
images
failed,
builds
shift
security
further
left.
It
was
a
really
great
starting
point.
Couple
of
companies
have
done
really
well
around
that
and
that
was
kind
of
I
call
it
the
walk
stage,
and
now
here
we
are
where
we're
entering
that
run
stage
over
the
next
year,
which
is
companies
realize
you
can't
use
traditional
security,
it's
not
just
about
vulnerability
scanning,
but
the
tooling
you
need
have
to
be
native
to
the
infrastructure
use,
so
they
have
to
be
native
to
kubernetes
or
other
form
factors
you
use
and.
B
Excitable,
they
can't
be
runtime,
they
can't
just
be
built,
they
have
to
integrate
into
your
bill,
they
have
to
integrate
into
your
deployment
and
they
have
to
do
things
at
runtime,
and
it's
that
consistency
where
the
language
or
the
common
language
being
used
is
kubernetes.
That
has
kind
of
brought
us
to
this
stage.
So
I
think
that's
kind
of
the
progression
we've
seen.
Companies
went
from
experiment
to
run
now
truly
operationalizing,
and
that's
where
coop
containers
and
the
new
security
form
factors
are
coming
in
I.
A
You
know
paradigms
and
so
I
think
it's
important
that
this
next
generation
of
tools,
let's
call
them
kubernetes
native-
for
lack
of
a
better
word
right
now
or
cloud
native
kubernetes
native
security
tools,
understand
the
the
different
phases
along
that
software
development
lifecycle
right
and
either
can
can
handle
that
whole
enchilada
the
whole.
You
know
the
whole
lifecycle
or
are
very,
very
tightly
integrated
with
tools
that
go
along
this.
Where
stack
racks
in
that.
B
Yeah
great
question,
so
the
way
I
think
about
this
is
is
that
it's
an
actual.
It's
an
interesting
thought
process
right.
If
you
think
about
it.
Traditionally,
especially
when
we
move
from
monolith
to
kind
of
the
the
evolution
is,
traditional
model
was
developers
build
hand
it
over
to
ops,
ops,
operationalizes,
deploys
it,
and
then
security
becomes
a
bunch
of
gatekeepers
and
in
this
world
on
every
company
wanted
to
become
your
horizontal
platform.
I
want
to
be
the
thing
you
plug
into
from
end
to
end,
and
integration
was
very
tough.
B
You
know,
API
driven
models
were
not
very
common
and
obviously
now,
with
the
rise
of
api's
and
RPC,
that's
hugely
hugely
advanced
that
the
way
we
think
about
it
is
is
that,
and
we
actually
tell
our
customers
this,
which
is,
is
that
the
way
you
should
think
about
kubernetes
is
kubernetes.
Is
that
horizontal
platform?
You
should
force
all
other
vendors
to
plug
into
so
nobody
should
be
your
workflow.
Everybody
should
build
their
workflow
as
part
of
your
coop,
your
CI
CD,
your
DevOps,
your
SDLC
lifecycle
and.
B
Another
approach,
so
when
we
think
about
safety
across
the
entire
lifecycle
of
build
deploy,
run,
we
think
about
different
use
cases,
not
different
features
at
every
stage
and
I
think
that's
a
very
important
part
of
it,
because
kubernetes
is
about
operationalization,
it's
operationalization
at
scale,
which
requires
automation.
So
what
that
means
is
is
that
at
the
build
process
we
want
to
make
sure
we
do
image
scanning
and
understand
vulnerabilities,
but
if
somebody
has
their
own
vulnerability
scanner
we
plug
into
the
ones
they
have.
We
don't
have
to
provide
our
own
at
the
deployment
stage.
B
We
run
things
like
CIS
benchmarks
for
docker
cube,
NIST,
PCI
HIPAA
at
runtime.
We
do
configuration
management,
networking,
firewalling
detection,
but
the
key
thing
is
the
output
of
all.
This
information
is
consumable
by
cube
itself.
The
way
we
produce
it.
So
that's
how
we
think
about
it.
So
when
we
want
to
make
sure
I
build
something
happens,
we
fail
the
build.
If
there's
vulnerabilities,
you
don't
want
to
introduce
into
production
a
deployment
time.
We
use
the
coop
native
constructs
like
admission
controllers
or
scaled
to
zero.
B
If
an
image
is
not
meant
to
go
or
if
it's
by
in
certain
policies,
a
grunt
rather
than,
for
example,
shimming
ourselves
in
as
a
proxy
or
inline
or
between
the
runtime
engine
and
a
host
which
causes
a
lot
of
operational
friction
and
you
become
part
of
critical
paths.
We
use
things
like
pod,
egress,
ingress
policies
to
program
layer,
3.
We
use
ISTE
on
service
mesh
for
layer
7.
We
use
the
notion
of
killing
pods
and
containers.
So
all
of
this
is
regular,
constructs
and
regular
motions
and
workflows.
B
A
100%
correct
and
that's
really
cloud
native
versus
just
integrating
into
kubernetes
and,
and
so
that
brings
up
the
whole
cloud
native
thing.
So,
for
instance,
you
spoke
about
service
smash
and
it's
the
there
will
hold
that
up
as
an
example,
but
there's
a
whole.
You
know
I
try
to
explain
to
someone
a
couple
weeks
ago
that
I
I
think
of
the
whole
cloud
native
computing
foundation.
A
You
know
kubernetes
gets
an
inordinate
amount
of
the
press
around
it,
but
it's
kind
of,
like
you
know,
an
American
naval
fleet
where
the
aircraft
carrier
right
is
is
the
the
flagship,
but
this
there's
more
to
a
fleet
than
an
aircraft
right,
there's,
battleships
and
destroyers
and
cruisers,
and
frigates
and
submarines
support
ships
and
Phineas
landing
ships.
We
we
see
all
of
these
in
the
cloud
native
world
right
and
some
of
them
some
of
them.
You
know
rectly
support
that
kubernetes
mission,
some
of
them
sort
of
exist
in
their
own.
A
You
know
independent
of
kubernetes,
if
you
will,
but
a
couple
of
things
number
one
strictly
from
a
passion,
point,
passionate
and
buzz
point
of
view
within
the
the
IT
community,
including
developers,
DevOps
security.
Folks,
look,
this
is
where
the
excitement
is.
This
is
where
people
want
to
play
right.
This
is
where
innovation
is
happening
and
then,
secondly,
as
a
result
of
all
this
innovation
and
passion,
where
we're
seeing
like
Internet
time,
crunched
even
tighter,
if
you
will
right,
things,
are
happening
boom
boom
boom
I
mean
it's
it's
hard
to
keep
up.
A
I
can't
wait
to
get
to
San
Diego
in
November
for
the
next
cloud
native
con
just
to
see
what
I
missed.
You
know.
Well
what
you
know
what
what's
next
and
that's
great
but
I
got
to
imagine
four
stack
rocks
here.
You
guys
are
saying
wow.
You
know
it's
good,
because
we
have
a
blueprint
going
forward,
but,
my
goodness,
we
we've
got
to
keep
our
our
tails,
and
you
know
in
this
and
keep
moving
as
fast
as
we
can
to
keep
up
with
this
talk
about
some
of
these
challenges.
Yeah.
B
So
I
think
you
know
when
you,
when
you
talk
about
cloud
native
computing
foundation,
there
is
a
lot
more
to
it
than
coop
you're
talking
about
things
like
Prometheus
and
onboard
core
DNS
container
D,
a
lot
of
other
tooling
dates
in
there.
The
best
way
to
think
about
this
is
is
that
this
ecosystem
is
meant
to
is
meant
to
accelerate
cloud
native
adoption
and
tooling.
That
is
required
to
do
this
from
building
to
monitoring,
to
servicing,
to
managing
across
the
board.
B
So
each
one
of
these
is
is
important
to
look
at
from
the
standpoint
of
what
is
the
use
case.
What
is
the
value
you
are
trying
to
add
to
your
business
and
the
reality
of
it?
Is?
You
may
not
need
a
lot
of
this,
or
some
of
it
may
not
be
necessarily
relevant
for
your
business.
So
the
way
we
look
at
it
as
sack
rocks
is,
is
that
we
kind
of
look
at
our
mission.
You
know
our
long-term
goal
is:
is
securing
distributed
systems?
B
You
know
whether
they're
running
on
using
a
container
or
serverless
an
on-prem
multi-cloud
public
cloud.
It
doesn't
matter,
however,
our
focus
is
kubernetes
and
a
kubernetes
service
mesh,
because
we
want
to
secure
this
new
cloud
operating
system.
So
the
way
we
think
about
this
is
you
know,
I'm
a
big
believer
that
in
enterprise
there's
no
such
thing
as
being
a
visionary.
You
know
there's
this
understood
set
of
problems.
If
you
solve
those
problems,
the
right
way,
the
customers
won't
actually
pay
you
for
it,
and
then
you
can
scale
that
and
they'll
solve
you.
B
You
know
ask
you
to
solve
additional
problems.
You
can't
suddenly
come
up
with
something
really
interesting
that
solves
no
particular
purpose.
So,
under
that
context,
our
general
trajectory
is
relatively
clear.
We
know
what
we
want
to
do.
We
know
we
want
to
make
the
lives
of
developers
easier.
We
want
to
know.
We
know
that
we
want
to
make
sure
they
use
their
native
tools.
So
if
we
alert
on
things
they
consume
it
through
things
like
slack
or
JIRA
or
pager
duty,
when
we
write
policies,
we're
writing
them
using
open.
B
You
know
policy
agent,
OPA
or
using
yam.
All
that
is
native
to
kubernetes,
so
the
biggest
is
lack
lock-in,
because
if
we
design
things
that
forces
a
proprietary
model
for
us,
those
proprietary
components
are
naturally,
by
my
experience,
the
things
that
come
in
and
end
up
being
a
dead
end
for
you,
because
a
new
technologies
build
that
extends
on
some
open
source
function
or
some
construct.
B
So
we
look
at
it
and
we
say:
okay
if
we
want
to
operationalize
developers,
if
we
want
to
give
security
folks
the
right
tools
and
if
we
want
to
be
able
to
scale
this
using
the
existing
constructs.
What
are
the
use
cases
we
want
to
center
around
so
that,
naturally,
positions
are
saying:
okay,
we
want
to
understand
visibility,
compliance,
configuration
management,
detection,
response
networking.
B
So
if
you
break
each
one
of
those
categories
down,
then
you
can
look
at
the
CNCs
foundation
and
look
at
the
tools
that
contribute
to
each
one
of
those
use
cases
and
the
way
we
approach
it.
As
we
say,
we
don't
want
to
reinvent
the
wheel.
We
don't
want
to
build
layer,
three
segmentation
controls
because
it
exists
in
kubernetes
pod
policies.
We
don't
want
to
create,
for
example,
killing
system
calls
that
are
unnatural
when
we
can
run
as
a
daemon
set
and
kill
pause.
B
So
in
that
world
we
build,
we
add
value
where
there's
a
gap
we
see
and
we
leverage
the
existing
infrastructure
and
tools
where
they
are
available
and
the
typical
model
we've
taken
is
as
I
call
it
kind
of
the
infinite
versus
the
finite
business
decision
making
is
is
that
we
look
at
our
company
as
a
long-term
bill.
So
if
we
know
you
know
kubernetes
that
IO
is
releasing
a
feature
set
for
networking
or
sto
is
coming
out
with
something
in
nine
months.
B
Rather
than
going
and
building
that
and
trying
to
commercialize
that
in
a
shorter
term,
we
wait
for
that
and
help
operationalize
that
the
right
way
the
safe
way
to
secure
way
once
it's
introduced,
because
that
way
we
also
tell
our
customers
listen.
Our
interests
are
aligned,
because
if
you
at
one
point,
don't
see
value
in
the
product,
you
can
rip
us
out
and
all
that
logic,
all
those
rules
and
heuristics
are
written
into
your
infrastructure
into
Kubb.
There's
nothing,
proprietary,
there's
no
lock-in.
A
What
I
see
and
that
that's
being
a
good
community
member
right
and
and
that's
one
of
the
I
I-
will
tell
you
had
this
conversation
yesterday
with
a
c-level
person
at
a
large
company
that
was
just
acquired
actually,
and
you
know,
we've
moved
from
the
even
an
open
source
which
of
all
this
cloud
native
stuff
is
right.
We've
moved
from
let's
calm
the
Richard
Stallman
years
right,
where,
where
it
was
kind
of
anarchy
and
the
heck
with
big
brother
too,
and
then
we
moved
into
a
period
where
big
brother
ran
open
source
right.
A
You
are
on
CDF
alley.
But
there
are
security
challenges
there
too
they're,
not
necessarily
kubernetes
specific,
though
more
and
more
we're
seeing
Cube
coop,
you
know
dominate
there
as
well
right
in
the
CI
CD
tools.
So
you
know
we're
gonna
see
the
same
sort
of
thing
there.
What
do
you
see
from
stair
cracks
point
of
view
for
that?
So.
B
This
is
an
area
where
we're
we're
really
interested
in
eager.
If
you
kind
of
think
about
our
product,
offering
you
know
50
60
%,
like
definitely
more
than
half
of
the
features
and
values
and
offerings
we
have
are
about
integrations
into
the
CI
CD
the
build
deployment
stage,
and
that's
a
really
interesting
component
for
a
couple
of
reasons
I'll
touch
on
and
why
I
think
that
CDF
is
very
important,
is
first
of
all
for
security.
I.
B
Think
security
has
always
struggled
to
do
things
like
enforcement
and
blocking,
and
the
reason
I
say
that
is,
is
that
security
always
lived
in
what
I
call
a
probabilistic
world.
You
know,
I,
have
this
application
running
I,
don't
have
any
context
of
who
built
it
when
they
built
it,
how
they
build
it
all
that
assets
and
inventory
information.
You
need
I'm
running
it
in
this
environment.
These
are
the
users
that
have
access
to
it.
This
user
is
the
highest
risk
user.
This
user
now
touches
D
services
at
every
hop.
B
We
increase
your
probability
about
some
action
and,
as
a
result
of
it
is
we
kind
of
got
into
this
cycle
where
people
were
saying.
Okay,
well
you're,
not
high
enough
confidence.
I
can't
enforce
this
if
I
can't
enforce
it,
I
can't
take
action
on
it.
If
I
can't
automatically
take
action,
I
can't
scale
it.
This
was
a
very
traditional
problem
that
existed
with
security.
B
The
reason
this
is
very
interesting
to
security
and
why
we
decided
to
go
full
and
invest
on
the
CI
on
the
CB
and
a
build
side
of
things
is.
Is
that,
in
my
opinion,
this
is
where
you
can
go
from
probabilistic
to
deterministic
security,
I,
understand
all
the
characteristics
and
all
the
attributions
of
my
application.
Now
that
it's
running,
if
I
have
deterministic
security,
I
can
automate
it.
I
can
take
actions.
I
can
respond
to
it.
I
can
send
that
information
back
to
the
developer
for
hardening
that
application.
B
So
if
I
go
from
probabilistic
to
deterministic,
I
can
automate
if
I
automate,
then
I
can
scale.
So
this
is
what
I
think
is
the
huge
value
coming
out
of
the
CI
CD
process
of
integrations
into
gitlab
and
github
and
build
tools,
because
you
can
collect
all
this
asset
and
inventory
information
and
progress
security
from
probabilistic
to
deterministic.
So
you
can
automate
and
scale
it
at
its
core.
That's
really
what
we're
trying
to
do
at
stock
Rox.
B
We
went
coop
native
because
we
want
to
have
access
through
coop
and
through
this
build
process
to
all
this
declarative
information.
So
we
can
make
security
deterministic
to
automate
it
for
users
and
to
be
able
to
scale
it,
and
that
is
what
developers
put
into
their
regular
work
flow
to
their
build
process
to
their
tooling
to
their
ticketing
solutions,
not
forcing
them
in
the
traditional
security
way
to
always
go
to
the
single
pane
of
glass
model.
A
A
What
are
the
challenges
in
this
computer
security,
world
right
and
and
and
what
we
can
do,
but
we'll
catch
that
on
the
next
one.
For
now,
a
legal
should
CEO
stack
rocks,
hey
thanks
for
being
our
guest
here
at
DevOps,
its
DevOps
chat,
but
with
the
video
twist
on
digital
anarchists,
this
is
Alan
Chimel
for
DevOps
comm,
a
security
Boulevard
container
journal.
You've
just
hopefully
enjoyed
another
DevOps
chat.
Video
and
we'll
speak
to
you
soon.