►
Description
What is cloud native security? What are the biggest security headaches when moving from legacy stacks to cloud native? Secure by default VS productive by default? Watch Anders Eknert and Steve Giguere answer questions about all things Cloud Native Security and share some of the worst security breaches they have experienced.
This session is a recording of the Cloud Native Northern Sweden meetup that took place on March 3. Moderator: Cristian Klein, Senior Cloud Architect at Elastisys.
A
A
B
Sure
so
amanda's
I
work
as
a
developer
advocate
for
styra
and
styra
is
the
company
and
also
the
inventors
behind
open
policy
agent
and
yeah.
For
for
my
own
account,
I
come
from
a
pretty
long
background
in
software
and
for
the
last
six
or
seven
years,
I've
mainly
been
involved
in
identity
systems
of
various
kinds
and
sorts,
and
that's
how
I
got
into
policy
and
policy
management.
C
Yeah
sure
sure
so
I
probably
similar,
I
started
off
writing
code
way
back
so
far
back
I'm
not
even
going
to
tell
you,
but
from
there
I
moved
into
a
lot
of
took
an
interest
originally
in
code
quality
and
then
moved
from
there.
It
kind
of
made
a
natural
progression
to
security.
So
from
there
I
started
we're
working
with
a
company
called
synopsys.
C
I
don't
mind
mentioning
them
where
we
had
sas
tools
is
tools,
software
composition,
analysis,
basically
the
whole
kind
of
deal
around
more
monolithic,
gen
security
and
then
taking
a
very
keen
interest
in
containers
and
kubernetes.
I
started
working
with
a
company
called
aqua
security
and
then,
from
there
into
stack,
rocks
stack
rocks
are
you
know,
obviously
a
fan
of
what
they
do,
they're
a
kubernetes
native
security
solution,
and
so
that's
where
I
am
now
and
I'm,
as
you
mentioned
cloud
native
security
advocate
talking
about
how
to
secure
the
cloud.
A
C
You're
supposed
to
start
with
an
easy
one,
so,
okay,
so
off
the
top.
My
head,
I
would
say,
lift
and
shift
the
notion
that
moving
to
cloud
is
as
simple
as
getting
a
cloud
provider
taking
what
you
did
putting
in
a
container
and
then
pushing
it
up,
because
to
do
that,
you're,
not
you're
kind
of
not
really
gaining
any
of
the
benefits
that
you
you
get
while
you
are
getting
some,
but
certainly
not
the
security
benefits.
I
wouldn't
say
that
you
get
from
doing
that
right,
you're,
not
gonna,
benefiting
from
re-architecting.
C
A
B
It
was
kind
of
simple
in
that
way
and
and
at
most
you'd
have
maybe
one
database
or
yeah
like
two,
if
you're
really
like
wild
and
crazy,
and
now
you
have-
and
now
you
have
all
these
disparate
systems,
interacting
with
each
other
and
often
like
in
many
organizations,
applications
that
span
not
only
like
technical
environments
but
also
across
so
many
different
teams.
So
you
have
to
connect
interact
with
and
with
like
the
politics
of
any
organization
in
order
to
to
to
kind
of
work
with
the
system
as
a
whole.
B
And
of
course
that's.
That's
that
poses
a
big
challenge
in
terms
of
security
as
well,
because
how
do
we
know
like?
How
can
I
keep
track
of
all
these
components
in
the
stack
like
I?
I
can
obviously
know
what
maybe
what
I
am
doing,
but
how
do
we
kind
of
keep
track
of
the
whole?
I
think
that's
a
major
challenge
in
in
the
cloud
native
stack
for
security,
but
for
for
it's
it's
it's
just
a
challenge
in
general,.
C
I
think
I
add,
can
I
add
what
anders
said
of
course
go
ahead
too.
All
right,
awesome,
yeah,
because
that
was
really
that
that
plays
off
the
opposite
of
all
the
next
step.
From
what
I
said.
So
if
you
didn't
rush
with
the
lift
and
shift
and
you
moved
into
a
microservice
architecture-
and
I
think
where
we're
going
is
that
a
monolith
would
have
been
all
java,
whereas
a
microservice
means
you're
going
to
move
into
new
languages
and
that
that
correct
me
enters
my
wrong.
But
that's
where
your
technology
stack.
C
B
C
A
Yeah,
I
know
let's,
let's
move
on
to
a
different
question,
but
I
think
I
think
this
is
it's
also
great
that
we're
having
both
of
you,
because
you
have
two
different
perspectives
of.
I
mean
your
kind
of
providers
of
two
different
pieces
of
cloud
security.
So
then
we're
having
a
question
right
now
from
the
audience.
A
C
Who
asked
that
all
right?
Oh,
I
actually
know
who
asked
that
all
right
I'll
get
them
later.
The
the
cloud
is
clouded
of
anything
to
me
means
to
leverage
the
new
environment
leveraging
the
advantages
of
the
new.
I
don't
know
I
just
said
paradigm,
I'm
going
to
stick
with
it,
I'm
going
to
own
it,
because,
if
you're
moving
into
cloud,
then
you
start
to
approach
the
world
of
more
ephemeral
objects
and
because
of
that
and
micro
service
architecture,
so
reduced
code,
the
size
of
reduced
code.
C
B
B
If
something
has
been
running
for
too
long,
it's
like
wow,
that's
that
sounds
like
a
that's
like
that's
like
an
anti-pattern,
so
yeah.
That's,
certainly
that
that
to
me
is,
is
central
to
cloud
the
cloud
native
concept
and
and
of
course,
that
has
that
has
an
effect
on
on
how
we
can
work
with
security
as
well.
B
That
would
be
like
you
owned
that
machine
and
you
could
probably
like
take
over
the
network
and
today
like
in
all
honesty,
that's
was
probably
not
going
to
be
a
big
deal.
If,
if
somebody
can
can,
I
can
get
roots
in
a
container
containerized
environment
running
in
kubernetes,
with
like
proper
security
measures
and
claims.
So
so
there
are
so
many
more
layers,
and
so
many
more
kind
of
lines
in
in
the
defense.
A
And
we're
getting
an
interesting
question
from
the
audience:
do
you
distinguish
between
cloud
native
security
and
cloud
security
in
general,
or
is
this
kind
of
like
the
same
thing
or
is
one
including
another,
or
there
are
separate
things
with
a
bit
of
intersection?
How
would
you
relate
these
to
cloud
native
security
versus
cloud
security.
B
A
C
I
think
there
might
be
a
perceived
difference,
because
when
people
think
of
cloud
native
security,
they
tend
to
side
towards
the
application
and
when
people
think
cloud
they're
thinking
more
about
the
ops
or
the
provisioning.
So
I
don't
know
that
that's
true
or
whether
that
really
makes
sense.
But
if
you
think
of
gartner's
terminology
like
cspm
cloud
security,
posture
management,
now
we're
talking
about
making
sure
the
provisioning
is
correct
and
maintaining
the
correct
posture
of
what
the
cloud
is,
and
yet
that
doesn't
seem
to
associate
at
all
with
ensuring
that
your
microservices
are
secure.
C
A
A
A
A
C
The
first
security
transactivity,
so
there's
a
lot
of
things
you
can
do
when
when
we're
talking
about
the
sclc
or
the,
I
assume
we're
talking
about
ci
cd
pipeline
in
integrated
activities
right,
and
I
think,
if
we're
moving
toward
cloud
native,
we're
probably
moving
toward
the
statistics
of
using
more
open
source
than
not
right.
We're,
not
writing
our
own
code.
Our
own
code
is
probably
20
tip
of
the
iceberg,
and
our
dependencies
are
far
larger.
C
So
I
would
be
looking
at
something
that
is
closer
to
either
an
sca.
So
looking
at
dependencies
and
open
source
vulnerabilities
that
are
available
like
the
low-hanging
fruit
that
both
the
bad
guys
can
exploit,
and
we
can
find
and
provide
some
sort
of
mitigation
around
that
does
blur.
If
we're
talking
about
containerization
and
image
scanning,
because
there
is
a
crossover
between
what
image
scanning
can
do
and
what
a
traditional
sca
can
do.
C
But
it
would
be
somewhere
in
that
space
to
ensure
that
we're
not
simply
pushing
obvious
vulnerabilities
into
our
running
area,
and
I
I
think
that
kind
of
is
a
is
like
a
tie
between
just
making
sure
we're,
not
misconfiguring
something
terrible,
and
that
was
goes
back
to
that
sort
of
cloud
security
conversation
we
just
had,
so
I'm
I'm,
but
that's
not
in
the
pipeline
or
not
in
the
traditional
application
security
pipeline,
it's
in
the
iac
pipeline.
So
I
don't
know
if
that's
that,
if
that's
what
michael
means.
A
B
Yeah,
I
I
think
it
would.
It
would
definitely
include
like
segmentation
to
make
sure
that
every
layer
of
the
stack
is
properly
isolated
from
the
other
layer
and
if,
if
there's
an
application,
that
has
no
need
to
to
talk
to
a
database
it
shouldn't
be
able
to.
And
if
there's
no
need
to
talk
to
another
application
and
it
shouldn't
be
able
to
so
any
kind
of
all
these.
B
A
B
I
think,
like
one
of
the
challenges
when,
when
you're,
when
you
see
like
a
new
cve,
is
posted
or
like
oh
there's,
there's
this
new
exploit
or
breach,
or
it's
often
just
finding
out
whether
we
are
affected
like,
even
though
we
know
like
for
sure
we're
running
this
software.
But
is
there
any
potential
chance
that,
like
that
somebody
from
the
outside
could
have
access
to
this
directly
because
there's
so
many
layers
and
and
and
proper,
like
segmentation
and
isolation
in
between.
A
B
Yeah,
of
course,
now
I
I'm
gonna
go
ahead
and
push
for
for
that
now.
But
obviously
policy
is
a
big.
It's
a
big
part
of
of
of
this
whole
cloud-native
security
thinking
and-
and
I
think,
like
policy
is
gonna,
be
there
whether
you
want
it
or
not.
It's
not
like
you
can
just
say,
like
okay,
we're
two
years
into
this
project.
Let's,
let's
apply
policy
like
you.
B
How
can
you
know
whether
whether
whether
you
had
a
reach
or
not,
if,
if,
if
there's
some
uncertainty
in
who,
who
did
who
was
allowed
to
do
something
so
yeah?
I
think
that's,
whether
you,
whether
you
use
oppa
or
not,
that's
not
like
the
main
point
here,
but
I
think
like
clearly
stating
that
the
rules,
the
boundaries
of
your
system,
that's
going
to
be
imperative.
A
Yeah,
I
want
to
say
that
you
kind
of
have
id
policies
anyway,
either
as
tribal
knowledge
or
hopefully
in
the
drawers
of
the
chief
informatica
officer.
Oppa,
takes
this
approach
one
step
further
and
basically
allows
you
to
codify
it
so
that
it's
it's
really
enforced
at
every
single
step
and
not
just
yeah
staying
in
the
drawer
of
somebody
and
I'm
forgetting
to
enforce
it.
C
B
You
actually
define
some
policy
on
on
what
that
means,
and
what
should
we
aim
for?
What
does
it
matter
like?
Is
it
just
gonna
if
it's
just
going
to
print
out
some
report
in
a
build
system
that
nobody
ever
is
going
to
look
at?
It
doesn't
really
matter
so
so
I
think
that's
kind
of
how
I
consider
policy.
A
C
Oh,
I
don't
have
the
shameless
plug
yeah.
That
was
actually
I
I'm
going
to
play
off
of
what
anders
said.
I
think
I
think
oppa
has
done
an
amazing
job
of
providing
a
standard
for
security
as
code,
and
that
is
totally
back
in
that
that's
an
absolute
essential
if
I'm
going
to
seamless
plug
stack
works,
does
a
version
of
that,
but
is
was
moving
towards
open
right
so
because
it
predated
open.
So
I,
if
I
were
to
shamelessly
plug
what
we
do,
it's
the
same
thing
just
slightly
different
flavor.
C
In
terms
of
saying
this
is
what
kubernetes
can
look
like.
This
is
what
deployments
can
look
like,
and
this
is
what
is
good.
This
is
what
is
not
good
and
enforcing
that
in
a
variety
of
different
ways.
That's
great
now,
if
we
take
the
philosophy
of
that
which
playing
off
what
you
said,
the
elimination
of
tribal
knowledge,
if
we
can
work
towards
anything
that
does
that,
then
that's
a
good,
that's
a
good
piece
of
tooling
or
automation
that
we
can
deploy
with
a
throughout
the
pipeline.
C
I
think
we're
we're
quite
familiar
with
things
like
going
way
back
to
static
analysis,
because
those
are
rules,
that's
essentially
a
compiler
that
looks
at
code
and
says
you
can
and
cannot
do
this
great.
It's
declarative,
that's
what
it
is
and
there
are
new
new
things
there.
So
I
think
that's
fine
to
have
things
like
that.
So
if
you
look
at
your
anything
you're
doing
an
image
to
see
a
early
or
image
scanning
and
you
ensure
that
those
gates
are
in
place
and
they're,
not
creating
more
problems
for
you.
C
That's
actually
really
important
right,
like
a
sas
tool
that
integrates
into
an
id
is
a
good
sas
tool.
An
sca
that
provides
pre-prioritized
results
is
a
good
tool,
but
one
that
doesn't
isn't
so.
These
are
all
important
for
highlighting
the
different
aspects
of
where
things
can
go
wrong
in
terms
of
your
code,
your
dependencies,
your
configuration
of
your
environment
and
then
translate
all
of
those
declarative
things
into
runtime.
If
you've
got
those
stages
worked
out,
then
you're
doing
small
amounts
at
every
phase.
C
Instead
of
one
big
amount
of
security
at
only
one
phase,
then
we're
off
to
a
flying
start
and
if
there's
a
lot
of
and
just
to
back
it
there's
a
lot
of
open
source,
you
can
use
to
make
that
happen
like
like
opus.
So
that's
that's
where
I
tend
to
start
start
with
the.
What?
If
there's
an
open
source
version?
Do
that,
because
it's
probably
easy
and
then
move
on
from
there
with
shameless
plugs
from
from
us.
A
Thank
you
for
your
answers
as
a
follow-up
to
the
tooling.
So
I
know
that
this
is
something
that
let's
say,
bothers
me
on
a
daily
basis,
and
it
seems
that
at
least
a
few
people
in
the
audience
are
also
bothered
by
it,
but
it
has
been
recently
reported
that
kuberetis,
for
example,
is
a
bit
struggling
between
coming
up
with
defaults.
That
gives
you
that
wow,
it
just
works
effect
versus
come
up
with
defaults
like
no
you
should.
It
should
really
make
it
very
hard
for
you
to
do
anything
insecure.
A
Unless
you,
you
know,
you
take
an
active
decision
to
disable
things
so
think
about,
for
example,
kubernetes
shipping
by
default
with
bot
security
policies
that
don't
allow
you
to
do
root.
That
would
be
so
awesome
from
a
security
perspective,
but
then,
probably
everybody
would
be
just
spamming,
the
kubernetes
slack
channel
with.
Why
are
my
containers
from
github
from
docker
hub,
not
working
and
so
on.
So
we
have
here
a
few
questions
in
in
kind
of
this,
this
same
area
like
how
can
we,
where
exactly,
should
the
security
votes
be?
A
Should
it
be
more
towards
secure
by
default
or
more
like
productive
by
default
and
also
okay,
once
you
change
those
defaults,
how
exactly
decide
how
far
should
you
go
into
securing
everything,
but
that
would
then
hamper
developer
productivity
versus
let's,
let's
first
aim
for
productivity
and
let's
say
then
we
secure
things
as
we
decide
that
the
risk
is
too
high
steve.
I
know
that's
quite
a
long
question.
I
hope
that
you
managed
to
I
managed
to
condense
it
very
nicely
steve.
Would
you
like
to
give
me
your
take
on
this.
C
Then
I
actually
like
secured
defaults.
I
like
I
like
the
idea
of
no
one.
Ever
probably
no
one
ever
does
this,
but
having
default,
deny
on
network
policies
such
that
the
application
comes
with
the
network
policies
that
it
needs
as
part
of
the
application,
so
that
you
have
the
network
policy
there,
I'm
here.
So
this
is
going
to
be
talking
to
these
things
and
we
only
talk
on
these
ports.
So
this
is
the
only
allowed
ingress.
That
would
be
amazing.
C
Does
that
happen?
It
might
prompt
that
to
happen,
but
it
would
be
good
if,
if
we
took
baby
steps
towards
secure
defaults,
because
it's
not-
I
don't
know
that
it's
part
of
our
culture,
yet
so
being
cognizant
of
the
fact
that
that's
a
nirvana
from
a
security
perspective.
I'm
also
aware
of
the
fact
that
we
just
might,
we
might
just
prompt
developers
to
find
backdoors
around
our
secure
defaults
in
some
way
or
another.
C
So
I
guess
I
like
what
you're
saying,
but
I
would
love
to
see
us
segment
the
world
on
our
journey
from
dev
to
production,
so
that
so
that
developers
create
something
in
some
form
of
world.
That
means
they.
They
have
awareness
of
what
those
security
defaults
are
they
learn
they
create
exceptions
with
intelligence
and
data-driven
knowledge
of
why
they're
doing
exceptions,
and
then
things
move
forward.
C
B
Yeah
sure
I
mean
for
for
me,
I
think,
one
of
the
main
drivers
of
of
good
like
secure
by
default.
It
needs
to
be
accompanied
by
by
a
good
like
usability
story
or
a
user
experience
just
just
take
tls,
for
example,
like
10
years
ago
it
was
still
kind
of
rare
to
have
encrypted
traffic
on
like
a
normal
blog
or
in
any
like
regular
website
it
just
wouldn't.
B
It
would
just
be
like
http,
because
if
you,
if
you
were
interested
in
having
like
encryption,
you'd,
have
to
call
one
of
these
providers
and
ask
them
like
you
had
to
talk
to
some
sales
person
and
like
it
was
just
such
a
pain.
So
even
if
it
was
a
good
idea
like
people
would
couldn't
be
bothered,
and
so
and
of
course,
like
the
actual
in
in
terms
of
like
technical,
what
you
need
to
do.
B
It's
it's
not
really
changed
in
those
years,
but
like
how
approachable
that
technology
has
become
like
and
how
easy
it
is
to
just
have
an
a
certificate
issued
these
days
compared
to
you
before
it's
just
it
just
made
all
the
difference.
So
now
there's
like
I
don't
know,
but
maybe
it's
I
think
it's
only
a
few
percent
left
of
any
traffic
online,
which
is
not
no
longer
encrypted.
B
So
so
so
yeah,
that's
if
you,
if
you
expect
to
have
like
secure
defaults,
you
better
make
it
easy
to
for
anyone
to
adopt
those
as
well
or
else
it's
like
people
are,
even
if
you
ship
something
and
it's
like
it's
secured
by
default.
The
first
thing
anyone
is
going
to
do
is
just
turn
every
every
toggle
off,
because
just
so
complicated,
so
so
yeah.
B
I
think
any
security
which
is
like
too
complex
to
grasp
or
to
kind
of
work
with
is
is
people
are
just
gonna,
disable
that,
because
it's
it's
just
painful
so
so
yeah.
I
I
wholeheartedly
agree
with
like
the
secure
by
default
philosophy,
but
it
needs
to
we
need
to
like
any
any
secure
system
which
is
unusable.
It's
it's
not
going
to
be
it's.
It's
not
going
to
be
either
it's
not
going
to
be
secure
or
usable,
because
people
are
just
going
to
disable
your
security
measures.
A
But
I
kind
of
get
a
slightly
different
twist
to
this
answer.
So
still
to
understand
correctly
what
I
mean
you
seem
to
both
agree
on
the
fact
that
we
need
to
make
security
easy
and
we
need
to
provide
proper
feedback
to
developers
on
why
certain
things
something
needs
to
be
secured
a
certain
way.
But
I
have
the
thing
that
steve
gives
a
bit
of
a
different
flavor
that
basically,
as
your
code
is
moving
from
dev
to
production,
you
should
be
more
and
more
restricted.
A
Like
I
mean
on,
for
example,
if
you're
having
your
development
call,
you
don't
really
care
that
you
don't
have
https
on
localhost
right,
that's
that's
perfectly
okay
to
have,
and
then,
as
you
move
into
for
example,
testing
there,
you
should
start
to
have
maybe
oppa
in
dry
mode
in
dry
run
and
then,
as
you
go
to
production
there,
really
the
policies
are
enforced
and
then
with
proper
feedback
for
the
ui.
Is
this
a
good
summary
to
to
give
to
what
what
your
answers
to
you.
C
That
that
is
that's
a
fair
summary
of
what
I
said
yeah.
I
think
it's
sometimes
difficult
to
accomplish
that.
I
mean
there
are
certain
organizations.
I've
worked
with
where
well
I've
seen
two
sides
of
the
coin.
I've
seen
one
people
saying
well,
we
need
to
keep
dev
wide
open,
so
we
can
make
sure
that
from
a
feature
and
acceleration
perspective,
we
make
sure
we
can
get
the
functionality
out
there.
A
C
Intelligence
feedback
loop,
that's
happening,
saying
it's
all
great:
it
all
works,
but
they're
never
going
to.
Let
you
do
this
over
here,
so
you
need
to
start
working
on
alternatives
for
this
this
and
this
or
you
need
to
put
this
in
place
or
you
haven't,
got
security
context
or
you
haven't,
got
all
the
other
things
that
are
in
your
ammo.
So
I
like,
I
like
the
idea
of
educating
developers
in
a
soft
way
earlier,
but
lets
them
lets
them
move
at
the
pace.
They
need
to
move.
B
No
for
sure,
and-
and
I
think
another
one
problem
with
having
like
one
or
kind
of
applying
security
to
prod
and
but
not
to
dev-
is
that
all
these
usability
issues
that
we
talked
about
before
they're
you're
not
going
to
be
really
exposed
to
them?
If,
if,
if
you
don't,
if
you
don't
see
them
in
depth,
but
you're
your
customers
they're
going
to
have
to
go
through
your
like
super
painful
multi-factor
authentication
process
every
time
they
log
in,
but
your
developers
they're
not
going
to
know
because
they're
not
really
affected.
B
So
I
think,
like
a
good
way
of
actually
making
sure
that
your
secure
processes
are
refined
and
kind
of
improved
on
continuously
is
to
to
actually
like
dog
food
that
part
of
your
whole
stack
as
well.
So
if,
if
security
is
painful
for
your
users,
it
it
should
be
painful
for
you
as
well,
at
least
to
some
extent.
C
Yeah,
it's
actually
off
the
back
of
that.
I
made
it
sound,
like
security
is
pushing
things
onto
developers,
but
it
works
in
both
ways,
because
if
you
try
and
put
your
security
measures
into
dev
and
then
the
devs
actually
find
a
way
to
bypass
it
there,
even
though
it's
just
warnings
or
something,
then
you
learn
like
okay,
that's
not
gonna
work.
We
need
to.
We
need
security
needs
to
learn
from
the
developers
as
well,
and
it's
a
great
opportunity
for
that
to
be
a
two-way
street
for
education.
A
Yeah,
thank
you
for
for
this
insight.
We
talked
a
lot
about
yeah,
open
policy
agent
and
also
vulnerability
scanners,
and
there
are
plenty
of
different,
open
source
projects
to
yeah
to
insert
in
your
security
cloud
native
security
pipeline.
I
have
a
question
from
the
audience
here.
What
should
be
the
value
that
enterprise
or
commercial
solution
bring
to
this
rich
ecosystem?
A
B
All
right,
yeah,
I
got
you,
I
think,
like
what
what
open
source
does
really
well.
This
is
kind
of
this
distributed
model
where
and
it
works
very
well
with,
like
the
cloud-native
model,
of
course,
where
you
have
like
a
thousands
of
instances
running
in
in
all
these
different
environments-
and
I,
like
these
small
components,
but
I
think,
like
a
good
space
for
for
the
enterprise
or
enterprises
is,
is
more
like,
where
you
still
need
some
kind
of
centralized
management
of.
B
What's
really
going
on
here
and
of
course,
there's
there's
some
there's
plenty
of
open
source
counter
examples
in
that
space
as
well,
but
but
but
I
think,
that's
like
kind
of
like
these
api
gateways
or
things
where,
where
there's
really
like
bigger
components,
managing
many
many
small
components.
I
think
those
are
those
are
often
kind
of
good
fits
for
for
enterprise
offerings
and
and
even
if
there
are
many
open
source
competitors.
B
It's
it's
often
kind
of
a
components
where
you
where
you
want
some
level
of
support,
because
not
not
only
are
they
kind
of
big
and
complex,
but
they're,
often
like
pretty
essential
to
anything
that
goes
on
in
like
a
firewall
or
something
like
that.
If,
if
it
goes
down,
it's
like
everything
goes
down,
and
I
think
any
any
component
like
that
is
is
a
good
candidate
for
for
for
building
some
business
around.
C
Yeah,
I'm
going
gonna
add
to
that
so
totally
agree
there.
I
think
what
we
what
was
touched
on
and
I'd
like
to
sort
of
add
to
is
it
seems
like
a
cliched
answer
but
scale.
A
lot
of
what
is
available
in
open
source
is
great
for
smaller
companies
or
teams
to
get
dip
their
toe
in
the
security
water
and
have
something
in
place
quickly
and
easily.
C
They
thrive
on
bringing
that
that
together.
The
other
aspect
like
there's
three
aspects
so
I'll,
try
and
keep
it
short.
The
other
one
is
taking
this
taking
the
answers
from
one
part
of
your
pipeline
and
using
them
later.
So
if
I,
if
I'm,
if
I'm
plugging
taking
a
vulnerability
scan
but
then
remembering
the
results
of
that
when
you
scan
the
deployment
so
that
you
bring
context
to
the
vulnerabilities
and
then
remember
remembering
that
as
you
run
into
runtime
and
knowing
where
your
risks
lie.
C
A
Interesting
answers,
thank
you
so
much
so
do
I
get
it
correctly.
Basically,
support
for
peace
of
mind
integration
and
then
also
well
code
is
one
thing
and
that
you
can
download
it's
open
source,
but
then
the
experience
that
went
into
how
to
use
that
code
and
how
to
modify
maybe
for
your
own
use
case
did
I
understand
correctly.
That's
kind
of
what
commercial
offerings
are
are
best
at
adding
value
over
open
source
solutions.
C
C
I
oh
boy,
I've
seen
multiple
instances
of
the
tesla,
the
public
kubernetes
dashboard.
I've
seen
I
have
found
in
live
presentations,
exposed
weave
scope,
examples
where
I
could
get
access
to
running
containers
with
a
prompt.
I
did
that
in
a
live
presentation
once
and
then
had
to
contact
them
immediately
afterwards.
C
C
I
was
once
working
with
an
organization,
a
large
organization
who
actually
like,
purchased
our
solutions
and
then
put
them
into
a
cloud
environment
but
did
not,
but
but
actually
exposed
the
front
end
not
just
to
their
internal
but
to
the
world,
which
is
actually
that's
worse
than
having
a
security
problem,
that's
having
a
security
problem
detailing
it
and
then
telling
the
world
by
accident,
so
that
was
found
very
quickly.
But
it's
it's
interesting
how
just
basic
misconfigurations,
particularly
of
cloud
soon
as
we
talked
about
cloud
security,
can
result
in
what
on
the
edge
of
catastrophe.
C
B
A
C
C
I
think
there's
still
ambiguity
about
what
cloud
native
security
means
just
kind
of
based
on
some
of
the
questions
that
we
have
so
there's
obviously
still
work
to
be
done,
but
I
think
we're
we're.
I
like
the
fact
that
we
talk
more
about
security
now
and
that
we're
having
sessions
like
this
is
is
pretty
good
and
I
think
the
bear.
C
What
used
to
be
the
bare
minimum
even
five
years
ago,
is
so
much
better
than
what
we
have
today,
thanks
to
organizations
like
cncf,
propping
up
a
lot
of
security
tools
in
open
source
and
then
extending
upon
those
with
with
just
awareness
that
seems
to
come
natural.
Now,
I'm
not
saying
like
we're
in
a
great
place.
Education
is
still
key,
but
I,
based
on
the
sort
of
questions
we've
got,
we've
come
a
long
way.
B
B
Don't
just
have
like
what
steve
called
tribal
knowledge.
That's
you
need
to.
You
need
to
actually
kind
of
write
down
and
you
need
in
preferably
in
some
like
declarative
language
or
some
where
you,
where
you
can
actually
where
you
can
work
with
requirements
and
policy
and
and
whether
it's
like
or
network
rules
or
whatever.
It
is
like
in
a
declarative
way
where
all
of
that
is
kind
of
in
under
version
control
and
where
you
can
work
with
best
practices.
As
code
review,
you
can
work
with
linters
unit
tests.
A
And
it's
a
very
nice
and
positive
message
and
feeling
to
take
home
right,
I
mean
yes,
we
still
have
we.
We
still
have
steps
to
take
before
we're
perfect,
but
we
have
come
a
long
way
to
improving
steve
anders.
Thank
you
so
much
for
joining
us
today.
Thank
you
also
to
the
audience
for
all
the
really
good
questions,
although
steve
might
have
not
appreciate
their
difficulty,
but
I
think
they
were
really
good
questions
and
they
were
definitely
very
good
too,
to
give
some
some
more
substance
to
the
discussion
yeah
with
that.