►
Description
Security isn't just for Ops teams anymore - what do we need to do to make security a focal point of app dev as well? And why is shifting security left important for containers and Kubernetes?
A
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
healing
from
welcome
to
the
season,
two
premiere
of
in
the
clouds
I
am
joined
by
the
one
and
only
kirsten
newcomer
security
extraordinaire
to
the
stars,
is
what
I'm
going
to
call
you
kirsten
the
the
welcome
to
the
new
season
of
in
the
clouds.
As
you
can
see,
we've
you
know
kind
of
spruced
up
the
place
thanks
to
our
marketing
communications
team
and
our
new
media
initiative
team.
A
Thank
you
very
much
for
all
the
graphics
and
work
that
we've
put
into
this,
and
you
know
with
that.
Let's
get
started
with
the
show
today
we're
talking
about
devsecops
or
shifting
left,
or
you
know,
improving
security
posture.
However,
you
want
to
phrase
it
in
your
organization
is
kind
of
the
way
we're
going
to
talk
about
it,
and
this
is
a
subject
close
to
my
heart,
but
it's
much
closer
to
kirsten's
hearts
kirsten.
Would
you
like
to
introduce
yourselves
and
tell
us
how
you
got
involved
with
devsecops.
B
Sure
so
kirsten
newcomer
director
of
security
strategy
for
the
cloud
platforms
bu
here
at
red
hat-
I
actually
it's
it's
been
kind
of
a
winding
trajectory
for
devsecops.
I
I
actually
have
been
in
the
software
field
for
longer
than
I
care
to
admit.
B
I
have
been
a
system
admin,
a
quality
engineers,
a
I've,
managed
a
release,
engineering
team
done
program,
management,
product
management
and
kind
of
that
combination.
B
You
know
interested
in
and
watching
for
a
time
and
and
so
we'll
talk
about
why
devops
versus
devsecops
phrasing,
maybe
a
little
bit
later
as
we
go
along.
A
Sure
that
makes
perfect
sense
so
folks
out
there
in
tv
land.
How
are
you
gonna
refer
to
whatever
the
streaming
thing
is
you're
watching
right
now,
please
feel
free
to
ask
questions
and
contribute
to
the
discussion.
We
have
no
problem
answering
any
questions
you
may
have
related
to
security
or
shifting
left
or
culture
change
in
that
regard.
C
C
You
know
it's
about
an
inch
two
inches
high
at
the
most.
A
That's
not
a
waffle
answer
like
that.
Actually
helps
us
get
to
the
root
of
the
question
right
like
if
it's
four
inches
or
higher
it
is
now
a
cake
right
like
this
is
discussions
that
we
don't
normally
have
right.
So
it's
good
to
know
that
if
we
can
safely
land
on,
if
it's
four
inches
or
higher
got
it
all
right,
actually,
cheesecake
is
literally
the
only
cake
I
will
eat
it's.
My
favorite
thing
and.
A
It's
great
stuff,
so,
on
a
more
serious
note,
one
thing:
I've
kind
of
learned
along
the
way
here
at
red
hat-
is
that
it's
rare
that
coming
to
work
at
redhead
is
the
first
time
you've
worked
with
a
red
hat
product
or
technology
or
even
project.
How
did
you
get
first
introduced
to
red
hat
itself?.
B
And
one
of
the
things
that
kind
of
our
partnership
with
ibm
led
to
was
an
engagement
with
the
eclipse
foundation
and
eclipse
ides
and
starting
to
deliver
developer
tools
built
with
and
for
eclipse
and-
and
that
was
my
first
exposure
to
open
source
and
it
was
fascinating
to
see
how
it
changed
the
market
right.
It
really
shifted
from
proprietary
ides
to
open
source
and
then
from
there
it
kind
of
moved
into.
B
You
know
linux
as
the
open
source
platform,
and,
actually
you
know
rational,
had
been
running
on
linux
for
a
long
time
and
then
just
sort
of
at
blackduck
software.
C
B
Love
that
stuff
and
and
and
then
also
honestly
at
when
I
was
at
blackduck
tim
yaton-
was
our
ceo
for
a
while,
and
tim
now
runs.
You
know,
he'd
been
at
red
hat
previously
he
came
back
to
red
hat
and
so
just
had
a
great
exposure
to
kind
of
you
know
both
the
community
open
source
and
then
what
does
it
mean
to
kind
of
actually
productize
open
source
and
make
it
ready
for
enterprise
use
so.
A
A
Toy
duck
rubber,
ducky
right,
and
so
my
son's
favorite
shower
bath
toy
is
the
black
duck.
B
A
Race,
yeah
awesome,
good
fun,
yeah
the
whole
office
thing
yeah,
so
speaking
of
you
know,
you
know,
offices
and
such
security
has
classically
been
siloed
right,
like
I
remember,
our
security
person
at
one
company,
like
literally,
was
in
an
office
in
the
back
of
the
data
center,
where
no
one
ever
ever
walked
or
went
unless
it
was
to
go
to
the
bathroom
so
yeah,
like
that's
how
I've
seen
you
know,
security
kind
of
classically
been
treated.
A
B
In
particular,
they
may
be
more
connected
to
operations,
but
even
there
kind
of
it's
been
more
about
defining
policies
that
then
the
ops
team
has
to
implement
as
procedures
and
make
sure
that
they
meet
and
when,
when
devops
first
became
a
thing
and
in
many
ways
you
know,
devops
is
a
follow-on
to
agile
development
methodology
right
kind
of
trying
to
again
apply
some
of
those
same
principles
not
just
to
the
development
cycle,
but
but
getting
that
code
released
early
and
often
also
right,
devops
is
is
about
that.
B
Even
though
it's
it's
intended
to
include
ops,
and
so
I
tend
to
talk
about
devsecops,
because
I
want
to
explicitly
call
out
that
teams
need
to
integrate
security
thinking
into
their
devops
life
cycle.
So,
just
as
the
develop
the
app
dev
teams
need
to
talk
to
ops,
to
figure
out
in
that
devops
process.
How
do
they
ensure
their
meeting
the
resiliency
requirements?
That
ops
has
you
know
various
configuration
regulatory
requirements?
B
They
also
need
to
be
sure
that
they're
meeting
the
security
requirements,
some
of
those
security
requirements
are
regulatory.
Some
of
them
are
internally
driven
and
are
about
policy,
and
so,
in
addition
to
shifting
security
left
right,
you
mentioned
how
security
often
comes
at
the
end,
there's
nothing
worse
for
a
development
team
than
getting
that
security
analysis
and
check
at
the
point
at
which
they're
ready
to
deploy
their
code
and
learning
that
they
have
to
go
back
and
and
start
over.
I
mean.
A
A
B
Right
or
there's
a
you
know,
a
vulnerability
with
scan
scan
was
run
and
you
discover
one
of
your
packages
has
that
scan,
and
now
you
have
to
upgrade
that
package.
It
has
that
vulnerability.
You
have
to
upgrade
that
package
to
the
newer
version,
but
that
package
has
dependencies
on
other
packages
and
so
you're,
not
necessarily
just
updating
one
package
in
your
application.
B
Also,
even
better
right
is,
if
you
use
something
like
the
ide
plugins,
that
red
hat
provides
where
you
can
do
dependency
analysis
and
security
and
get
security
data
in
your
ide
real
time
right,
so
that,
even
before
you
check
in
you
can
decide,
you
can
learn
whether
there's
something
that
maybe
needs
to
be
fixed,
but
at
minimum
doing
it
during
that
build
process
right,
we
always
used
to
talk
about
the
stats
right.
How
much
time
does
it
take
to
fix
a
bug?
That's
found
in
production.
C
A
B
Absolutely
especially
when
it
comes
to
cloud
native,
but
not
just
for
cloud
native,
but
when
we
think
about
containers
and
kubernetes
right
best
practices,
you
never
patch
a
running
container,
and
why
is
that?
Because
a
container
orchestration
solution
is
designed
so
that,
if
a
running
instance
of
your
application
goes
down,
a
new
instance
will
automatically
be
deployed
from
the
container
image
from
the
pod.
So
if
you've
patched
or
running
a
running
instance
and
not
rebuilt
your
image,
you
lose
that
fix
as
soon
as
the
redeploy
happens
right.
B
So
you
need
your
pipeline
that
devops
that
devsecops
pipeline
to
have
as
much
automation
as
possible
so
that
you
can
respond
quickly
when
new
issues
are
found
at
whatever
layer
of
your
application.
They're
in.
Are
they
in
the
base
image?
Are
they
in
your
runtime?
Are
they
in
the
custom
code
that
you're
writing
the
code?
That's
key
for
your
app!
You
need
automation
for
building,
and
ideally
you
know
and
again
for
for
security
testing,
but
also,
ideally,
for
you
know,
qe
testing.
B
B
That's
it's
a
really
interesting
question,
so
some
kinds
of
scans
make
more
sense
in
different
places
right,
so
so
that
dependency
analysis.
If
you
can
find
a
tool
that
will
give
you
dependency
info
in
your
ide.
C
B
Big
value
same
for
vulnerability
analysis,
but
most
vulnerability
scanners,
which
sometimes
are
also
software
config
analysis
scanners,
right,
they
figure
out
what
packages,
what
what
code
is
in
the
the
blob
that
you're
analyzing
and
they
tell
you
what
those
packages
are
and
then
they
map
to
known
vulnerabilities.
B
Those
are
best
run
either
in
your
in
your
artifact
repo,
your
container
repository
right
as
soon
as
you're
down,
especially
if
you're
using
external
content.
As
soon
as
you
pull
it
down,
scan
it
yeah.
That
includes
content
from
red
hat.
We'll
tell
you
if
we
know
about
vulnerabilities,
but
you
should
you
should
do
the
belt
and
suspenders
scan
it
anyway.
B
Exactly
exactly
so,
and
then
those
scanners
are
typically
good
in
the
build
process
right.
So
if
you
can
do
dependency
analysis
solutions
like
sneak
in
the
ide,
that's
a
that's,
that's
a
great
starting
point.
If
you
and
then
build
vulnerability
analysis,
any
type
of
static
analysis
scanners
have
pros
and
cons
right.
There
are
things
like
coverity
other
solutions
that
that
kind
of
analyze
your
code
for
the
quality
sonar
cube.
You
know,
what's
what's
the
quality?
Are
there
things
like
cross-site
scripting
risks
in
your
code?
B
You
want
to
do
those
as
early
as
possible
too,
and
most
of
those
scanners
require
some
tuning
so
yeah
because
yeah
you
wind
up
with
false
positives,
etc.
So
those
ideally
would
be
kind
of
in
that
ci
process
as
well,
and
then
you
want
for
for
runtime.
You
know
for
for
dynamic
analysis.
B
B
That
is
what
what
exactly
you
know
as
close
as
possible
to
your
production
environment
and
that
you
know,
if
you're,
going
to
do
dynamic
analysis.
You
do
that
in
that
test,
environment,
along
with
any
automated
user
acceptance
tests.
Things
like
that
and
and
again
one
of
the
values
of
containers
and
kubernetes
right
is
that
you
can
do
something
you
can
have
an
openshift
cluster.
That
looks
just
like
your
production
cluster,
your
development
team,
your
user
acceptance
team.
They
can
have
the
same
environment,
the
same
constraints.
B
If
something
slips
through
in
in
your
testing
and
hits
in
production,
but
you
also
you've
got
that
that
same
deployed
environment
and
then,
finally,
you
really
want
to
add,
like
oftentimes
and-
and
I
feel
like
in
our
conversation-
I've
been
guilty
of
this.
When
we
talk
shift
left,
we
talk
devsecops,
we
think
about
it
as
devsec.
That
is
what
are
the
security
tools
that
are
useful
to
the
developer
and
I
think
that's
partly
because
that's
the
area
that's
been
neglected,
but
devsecops
means
also
set
ups
right.
B
So
what
are
the
security
tools
that
are
useful
in
operations
for
container
and
kubernetes
right?
So
you
want
runtime,
behavioral
analysis.
You
want
things
like
pod
security
policies
or
security
context,
constraints,
admission,
control,
policies
that
help
you
control.
What,
whether
what
privileges
a
container
is
given
when
it's
launched
and
also
you
want
processes
and
gates
in
place
that
ensure
you're
only
pulling
approved
images
onto
your
production
cluster.
So
it
really
is
the
full
life
cycle
that
you
want
to
be
thinking
about.
A
B
In
tandem-
and
I
think
you
know
that's
a
place,
that
is
where,
where
things
are
still
where
the
the
the
community,
the
the
software
community,
is
still
working,
I
think,
but
it's
also
one
of
the
reasons
I'm
really
excited
by
red
hat's
recent
acquisition
of
stackrocks,
because
they
have
the
ability
to
leverage
data
collected
during
the
build
process
right
during
that
they
do
both
vulnerability
analysis,
but
app
config
analysis,
which
is
also
important
right,
is
the
is
the
metadata
you
know
for
your
for
your
container
and
your
pod
are
they
are?
B
Are
they
asking
for
privs?
Do
they
have
embedded
secrets
that
data
can
be?
You
know
that
content
can
be
analyzed
and
the
data
collected
during
the
build
process,
and
then
it
can
be
used
to
buy
an
admission
controller,
that's
deployed
on
the
cluster
and
where
you
get
to
say
you
know,
okay,
any
pods
that
have
these
characteristics
may
not
be
deployed
to
my
cluster.
So
that's
one
of
the
ways
that
you
you.
We
really
want
tooling,
that
leverages
the
data
collected
early.
That
wasn't,
you
know
if
it
wasn't
fixed.
A
Yes,
exactly
so,
you
know
we
know,
devsecops
is
important.
We
know
that
we
want
to
bridge
the
divide.
How
do
we
make
that
divide
bridged
in
the
kind
of
the
the
cloud
native
and
kubernetes
environments
right,
because
it's
a
very
fast
moving
right
like
if
you
look
at
some
of
the
reports
from
the
last
couple
years,
right
like
the
average
lifetime
of
a
container,
is
measured
in
seconds?
You
know
that
kind
of
thing
right,
like
it's
almost
like
containers,
are
reaching
serverless.
C
C
B
And
I
think
I
have
to
answer
both
on
the
tooling
and
the
people
side,
but
also
yeah.
Certainly
there
have
been
some
interesting
reports
about
you
know
that
have
been
published
about.
What's
the
length
of
time
that
that
containers
are
on,
I
mean
systig
did
a
really
interesting
analysis
and
I
think
that
their
their
average
time
for
the
majority
of
containers
in
their
in
their
analysis
was
five
minutes
wow.
So
at
least
it
wasn't
five
seconds.
A
B
I
look
at
that,
though,
and
I
wonder
how
many
of
those
are
init
containers
or
you
know
how
much
do
init
containers
and
side
cars
affect
that
average
time
span
and-
and
I
don't
think
we
know
yet.
At
least
I
don't
know,
I'd
love
to
to
have
a
conversation
with
that
team
and
learn
more
about
the
data
behind.
You
know
that
that
they
collected
that
said
right,
we
should
be
assuming
that
a
container
can
go
down
and
be
replaced
at
any
point
right.
B
So
the
cicd
pipeline
for
your
for
your
app,
but
also
in
place
for
your
platform
right.
How
are
you
managing
deployment
of
your
kube
cluster
and
are
you
prepared
to
redeploy
at
any
moment?
Should
crypto
miners
be
discovered
on
your
platform,
for
example
right?
So
you
really
want
to
take
that
devops
approach.
B
That
is
understood
to
be
useful
for
apps.
You
want
to
do
that
for
your
platform
too,
so
you
want
to
think
about
it
in
a
git
ops-like
way
right,
everything
should
be
infrastructure
is
code,
it
should
be
monitored,
it
should
be
assessed
and
evaluated
and
then,
once
it's
approved
and
signed
off
on,
I
should
be
able
to
deploy.
B
As
you
know,
anytime,
I
want
and
and
so
sort
of
that's
the
tooling
side
right
and
your
tooling
can
be
there
a
range
of
tools
that
can
help
you
there.
You
know,
there's
there's
for
the
apps,
there's
things
like
jenkins
and
techton
the
new
you
know
kind
of
more
cloud
native
pipeline
for
your
operations.
B
You
know
ansible
terraform,
all
sorts
of
different
things
and
argo
cd
actually
is
a
really
interesting
new
player.
That
kind
of
spans,
both
of
those
for
a
kube
environment
and
so
leveraging
argo
cd,
is
a
great
way
to
go
too,
but
but
store
your
infrastructure
treat
it
your
code,
your
configs
treat
it
as
if
it
is
source
code
right
version,
it
manage
it
automate
automate
all
of
that
and
then
on
the
people
side.
B
Back
to
your
silo
point,
we
collectively,
including
kind
of
the
you
know,
there's
the
bottoms
up
in
the
top
down
thing
and
and
people
behave
in
the
way
they're
motivated
right.
So
how
do
you
help
that
security
team
that
has
been
siloed
to
become
partners
in
the
process
of
building
your
devops
pipeline
for
both
apps
and
infrastructure?
B
And
one
of
my
favorite
customer
examples
here
is
a
is
a
team
in
the
federal
sector
who
their
chief
of
cyber
security
decided
that
his
team
of
security,
architects
needed
to
learn
the
development
process
and
something
about
the
tools
that
the
developers
use
right
and
that,
if
he
couldn't
and
if
and
that,
until
they
learned
that
they
couldn't
be
effective.
Advocates
for
helping
get
the
process
into
a
place
that
worked
for
everybody.
B
They
they
really
needed
to
shift
their
thinking
and,
and
that
takes
incentives
right
for
a
culture
to
make
that
kind
of
for
an
organization
to
make
that
kind
of
cultural
change.
You
have
to
have
somebody
who's
willing
to
support
that
and
help
the
team
be
rewarded
for
for
making
those
kinds
of
shifts.
A
Yeah
questions
just
came
in
like
what
tools
would
you
recommend?
You
know
that
kind
of
thing
and
I'm
just
gonna
drop
a
link
just
for
you
know
full
posterity
to
the
cncf
landscape,
that
suspect
specific
security
compliance
category.
But
what
do
you
think
you
know
are
good
tools
to
run
against
like
prod,
for
example,.
B
Uh-Huh,
okay,
so
I
actually
I'm
gonna
hit
this
from
a
and,
and
you
know
so
so
one
of
the
things
we
do
at
red
hat
is:
is
we
work
closely
with
our
partners
to
ensure
that
the
solutions
are
are
certified
to
run
against
openshift
right?
B
And
you
know-
and
that
includes
the
ecosystem
of
security,
isv
partners
right
and
so,
when
we
think
about
it,
there's
there's
a
lot
of
different
categories
to
look
at,
and
in
and
and
so
one
thing
to
consider
is
you
know
value
for
your
buck
right?
Can
you
get
a
solution,
a
tool
that
helps
you
both
with
the
pipeline
and
at
run
time,
and
there
are
a
number
of
of
our
partners
who
who
do
that
certified
partners?
B
You
know,
in
addition
to
stack
rocks,
which
is,
is
gonna,
is
being
rebranded
as
red
hat
advanced
cluster
security.
We
also
have
partners
like
systig,
palo,
alto,
prismacloud
solution,
aqua
security.
B
Pretty
much
all
of
those
partners
have
solutions
that
at
a
minimum
you
can
use
vulnerability
scanning
in
in
the
pipeline
as
well
as
in
a
running
cluster
and
and
and
many
of
them
have
image
assurance
capabilities.
Just
like
stack
rocks
does
and
then
you
really
want
to
be
looking
for
I'm
going
to
share
for
a
minute.
You
want
to
be
looking
for
runtime
analysis
capabilities
right,
behavioral,
runtime
analysis
is
a
great
win.
B
B
But
runtime
behavioral
analysis
is
a
great
addition
for
the
production
environment
and,
and
then
you
know,
are
there
solutions
that
help
you
do
more
with
network
controls
right,
so
kubernetes
has
network
policies.
B
You
have
to
figure
out
how
to
configure
your
environment
appropriately.
For
that
there
are
solutions
that
can
auto
suggest
network
policies
to
you
for
you
and
and
that's
another
way.
You
can
also
bridge
the
dev
and
the
production
environment
right
if
you're
running
in
a
in
a
test
cluster-
and
you
try
out
some
of
those
suggested
policies
that
gives
you
an
idea
of
what
do
you
want
to
actually
deploy
with
and
then
deep
audit
and
monitoring
is
key
right.
B
So
out
of
the
box
openshift
includes
you
know,
auditing
is
on
at
the
host
level.
Api
server
auditing
is
on
for
kube,
but
many
of
these
solutions
also
add
deeper
data
collection
and
correlation,
and,
and
so
you
can
kind
of
get
an
idea
here
of
the
partners
that
we
work
with
the
partners.
That
and
again
you
know
the
ones
I'm
going
to
know
about
are
the
ones
that
are
certified
to
work
with
openshift,
but
most
of
them
work
with
other
kube
distros
as
well.
A
Yeah,
that's
great
yeah.
We
we
love
the
tools
that
work
with
kubernetes.
A
B
Well,
yeah,
one
of
the
things
I
like
about
it
again
is
that
you
can
see
that
it's
showing
up
in
multiple
boxes
here
and-
and
so
we're
really
looking
forward
to
so
it
does
that
deeper
data
collection.
It
does
the
auto
suggest
for
network
policies.
It
gives
you
a
visualization
of
the
network
policy
layer,
openshift
service,
mesh,
visualizes
layer,
seven
with
with
service
mesh
policies,
but
with
stack
rocks
you
get
that
network
policy
layer
visualization
as
well.
B
I'm
really
looking
forward
to
what
we're
gonna
be
able
to
do
with
service
mesh
and
stack
rocks
together.
We
get
behavioral
analysis,
but
you
can
see
right.
We
show
up,
we
tick
a
lot
of
these
boxes,
and
so
when
we
think
about
that,
you
know
infinity
arc
that
that
that
you
see
for
devops
or
devsecops.
B
We
really
feel
like
stackrocks
helps
with
that
and-
and
we're
also
really
excited
about
the
shift
left
elements
right-
that
we
can
do
that
early
analysis,
leverage
that
data
for
the
the
admission
control
policies
and
we're
going
to
continue
to
work
with
all
of
the
partners
here
right
so
sneak
does
the
dependency
analysis
again.
As
I
mentioned,
there
are
other
partners
who
show
up
in
a
number
of
these
boxes,
and
so
it's
it's
not
just
about
what
we
offer
from
red
hat.
B
We
also
really
expect
right
we're
going
to
we're
going
to
get
a
lot
of
value
from
being
able
to
tightly
integrate
the
red
hat.
Acs
stack,
rocks
solution
in
with
openshift,
just
because
we're
now
part
of
the
same
company
that
we
can
do
that.
A
Yeah
and
I
have
to
say
that,
like
when
I
heard
the
news
that
red
hat
was
acquiring
stack
rocks,
it
was
a
huge
relief
because
I've
worked
with.
You
know
the
various
cube
contacts
whatever
with
a
bunch
of
people,
for
you
know
that
worked
at
stack
rocks
and
they
all
seem
to
be
great
people.
So
it's
not
where
the
technology
is
great
and
the
people
are
great.
So.
A
B
That's
a
it's
a
great
question.
I
think
that
you
know
you
really
want
it's
it's
about
the
success
of
the
business
right,
and
so
the
business
cares
about
getting
capabilities,
getting
new
solutions,
differentiating
innovative
solutions
out
to
the
market
as
quickly
as
possible
and
ensuring
customer
satisfaction
along
the
way
right.
So
when
you
think
about
meeting
those
goals,
security
has
to
be
part
of
that,
and
the
sooner
that
you
can
help
the
organization
address
their
concerned.
Security
concerns
the
faster
you
can
deliver
and
the
better
you
can.
You
can
address
customer
satisfaction
right.
B
Customers
don't
want
to
have
to
update
because
of
vulnerability
that
has
been
known
for
four
years.
Right
is
present
in
something
you
just
shipped
right.
They
understand
if
it's
a
newly
discovered
vulnerability.
That
happens.
Everybody
understands
that.
But
if
you
know,
if
the
work
wasn't
done
early
to
assess
for
vulnerabilities
that
have
been
around
for
a
while,
and
that
can
happen,
we've
we've
seen
breaches
that
have
been
due
to
situations
like
that.
There's
a
fix
for
the
vulnerability,
it
wasn't
applied
yeah.
B
So
it's
all
about
value
to
the
business
value,
to
the
end
user
and
the
customer,
and
if
you
can
help
your
management
understand,
if
you
yourself,
it
helps
if
you
believe
it
too
right
as
a
developer.
You
believe
this
is
going
to
make
your
life
easier,
you're
going
to
deliver
more
quickly.
If
you
have
this
ability
that
helps
a
lot
I
I
did.
This
was
a
number
of
years
ago
now,
but
I
did
talk
to
a
customer
who
the
gentleman
he
was
in
the
development
team.
He
would
have
loved
to
do
vulnerability.
B
B
That
was
a
really
interesting
one
and
yeah.
So
it's
like
so
you
so
thinking
in
terms
of
not
just
technical,
but
a
combination
of
technical
and
business
value,
right,
helping
and
helping
convince
your
management
and
then
get
your
management
enlisted
to
help
convince
other
players
that
this
is
the
right
thing
for
the
business.
A
You
know
it's
interesting.
You
mentioned
that
that
case
of,
like
the
security
team,
wouldn't
let
them
in
because
that
has
actually
happened
to
me
like
working
in
the
devops
space
right
like
trying
to
secure
systems
and
networks,
and
everything
is
like
well
if,
if
you
have
the
nesa
scanner
and
I
have
to
come,
submit
a
ticket-
and
it
takes
a
couple
days
for
you
to
get
back
to
me
on
any
fixes
I
get
in,
can
I
just
get
access
to
the
nesa
scanner,
so
I
mean
like
we
had
licenses?
B
A
C
A
B
C
B
The
best
thing
you
know
the
most
successful
teams
find
a
team
that
they
can
pilot
these
changes
with
and
so
that
they
have
an
opportunity
to
iterate
on
the
changes
work
together.
So
you
gotta,
ideally
you'd,
find
somebody
on
that
security
team.
B
A
So
it's
funny,
you
know.
Technically
I
work
in
you
know
a
marketing
kind
of
function,
but
it's
more
like
a
like
an
ops
advocate.
If
you
think
of
like
developer
advocates,
it's
like
an
ops
advocate
kind
of
deal
and
I
can't
express
enough
how
important
it
is
to
like
market
what
you've
done
better
right.
Like
I
tell
people
all
the
time,
there's
a
lot
that
devops
can
teach
marketing
and
there's
a
lot.
C
A
Open
source-
or
you
know
whatever
it
is
you're
doing
to
other
people
in
a
better
way
right
like
so
that
you
can
show
people
that
your
pilot
is
successful
in
an
effective
way
right
like
look
at
actual
numbers
and
metrics,
and
how
this
could
change
velocity
or
improve
user
experience.
Right,
like
things
that
you
know,
leadership
is
going
to
care
about
absolutely.
A
A
A
That's
what's
going
to
get
vp's
attention,
you
know
yeah
and
tony
tv
points
out
like
language
is
a
barrier
sometimes
true,
so
you
have
to
kind
of
adapt
yourself
to
the
language
of
the
people
you're
talking
to
and
that's
one
of
the
biggest
things
I
worked
learned
when
I
was
on
the
ansible
team
on
the
product
marketing
side
was,
you
know,
adapting
yourself
to
the
persona
you're
talking
to
is
very
important.
B
Yeah,
it's
that
that's
and-
and
we
really
kind
of
had
to
think
about
that-
you
know,
as
we
were
kind
of
re-recrafting
a
bit
of
our
language.
You
know
around
how
we
go
to
market
with
our
security
story,
partly
due
to
the
stackrock's
acquisition
right.
We
wanted
to
do
that,
build,
deploy
and
run
as
a
key
message,
but
those
words
you
know
they're
great
for
a
devops
team,
but
the
security
team
is
thinking.
How
do
I
detect
problems?
How
do
I
protect
my
environment?
How
do
I
respond
to
an
incident?
B
A
Right,
they
think
all
about
risk
management.
Absolutely
so
there's
a
a
change
occurring
in
the
security
landscape
inside
kubernetes-
and
you
know
this
is
kind
of
a
hot
button
topic
for
me
right
now,
because
we're
trying
to
work
on
the
blog
post
for
this
and
it's
kind
of
a
nightmare.
So
you
know
like
pod,
security
policies
are
being.
A
B
B
Go
away
but
with
a
replacement
right
and
so
for
anybody
who's
interested.
There
have
been
conversations
happening,
there's
I'll
try!
I
might
have
the
link
up
to
the
to
some
of
the
proposals
there
are
a
couple
of
if
I,
if
I
can
find
it
I'll
post
it.
There
are
a
couple
of
proposals
in
place
for
ways
to
to
replace
there's
something
called
pod
security
plus
plus
and
there's
something
called
the
bare
minimum
pod
security
policy.
B
B
And
I
think
that
that's
that's
partly
where
the
community
is
is
thinking
right
is
that
so
pod
security
policies
are
great
and
openshift
uses.
You
know
the
openshift
uses
security
context,
constraints
which
were
kind
of
the
predecessor
to
pod
security
policies,
right
security
policies
never
fully
took
off,
and-
and
the
truth
is
that
both
that
that
both
sccs
and
psps
have
a
require
a
degree
of
understanding
and
they
have
a
level
of
complexity
that
can
create
frustration.
B
You
can't
turn
it
off
yeah,
so
the
community-
I
you
know
kind
of-
is-
is
leaning
towards
the
concept,
at
least
and
and
by
the
way,
sig
off
or
sig
security.
If
you
want
to
participate
in
the
conversation,
hopefully
you
can
share
the
the
links
that
I
put
awesome
to
the
two
different
proposals.
B
Active
discussion,
going
on
and
and
kind
of
the
thinking
is
that
around
you
know
we
might
land
on
something
that
says
you
have
that
minimum
three
policies
available
to
you
kind
of
a
red,
yellow,
green
right,
green
means
that
it's
the
most
secure
and
and
maybe
that's
what's
on
by
by
default
or
but
you
have
the
option
to
use
a
less
secure.
B
That
would
be
yellow
and
a
very
permissive
which
might
be
red
and
we're
also
seeing
kind
of
the
rise
of
an
increasing
interest
in
opa
gatekeeper
as
a
way
to
write,
complex
policies
and
so
kind
of
there's.
There's.
The
conversation
has
been
about
okay,
a
default
built-in
set
of
capabilities
that
are
perhaps
simpler
and
easier
to
use
than
the
current
pod
security
policies
similar,
but
but
simpler,
and
then
for
complex
use
cases,
opa,
gatekeeper
or
something
comparable
would
be
the
way
to
go,
and
then
there's
a
debate
about.
Can
those
be
used
together?
B
Would
you
use
one
instead
of
the
other,
assuming
we
have
these
default
policies?
Can
we
make
it
easy
for
those
to
be
represented
in
something
like
opa
gatekeeper
in
case
you
want
to
switch
to
a
more
complex
environment
right?
How
do
you
do
all
of
this
in
a
way
that
doesn't
break
what
you're
already
doing
or
there's
there's
going
to
be
a
migration
right,
no
question,
but
but
let's
say
once:
we've
migrated
and
you're
up
and
running
with,
say
the
new
defaults,
and
now
you
need
something
more
complex.
A
A
Who's
interested
yeah
anybody
who's
interested.
Let
me
drop
the
link
to
cairo
in
here
too.
Come
on.
You
can
do
it
mouse,
I
believe
in
you
cool.
So
you
know
the
the
linux
kernel,
capabilities
of
namespaces
and
all
the
fun
network,
ports
and
file
systems
and
everything
else.
You
have
to
manage
that
too,
along
with
the
platform
there's
a
question
in
here:
do
you
believe
that
distributions
like
deviant
and
rel
have
a
monopoly
on
the
best
audits?
Today
I
wouldn't
say
it's
monopoly
on
the
best
audits,
but
there's.
B
Ones
and-
and
I'm
not
sure,
what's
meant
by
audit
in
this
case
audit
by
whom
or
audit
capabilities
in
in
the
product
right.
So
you
know
maybe
we'll
hear
back
from
the.
B
And
and
in
the
meantime
I
can
riff
a
little
bit
so
so
certainly
you
know,
I
would
expect
that
any
of
these,
so
first
of
all
one
of
the
cool
things
about
pod
security
policies
and
sccs
is
it
gives
the
cluster
admin
a
way
to
manage
access
to
linux
capabilities
host.
C
B
Etc,
without
them
having
to
be
linux
admins,
they
might
need
to
learn
about
these
things,
but
they
never
have
to
work
at
the
os
layer
to
protect
the
host
because
they
can
prevent
access
to
the
host
network.
The
host
file
system
with
a
psp
right.
I
think
it's
important
that
we
maintain
some
of
that
basic
set
of
capabilities
in
the
replacement
solution.
B
We
need
to
give.
We
need
to
give
kube
users
a
way
to
continue
to
do
that
and
and
again
maybe
it's
just
not
going
to
be
as
many
different
factors
that
can
be
tweaked
in
in
the
replacement.
A
B
Right
and
and
then
the
runtime
comes
into
play
right
are
you?
Is
the
runtime,
you
know
running
unconfined,
or
is
there
a
set
comp
policy
applied
to
the
time
that
comes
into
play?
That's
something
that
is
still
separate,
I
believe
from
the
replacement.
It's
I'm
going
to
make
myself
a
note
to
ask
in
our
next
conversation.
B
You
know
how
they
view
setcomp,
in
fact
around
all
of
this
and
then
in
terms
of
the
audit
capabilities
right
so
and-
and
I
I
just
I
know-
rel
better
than
debian.
So
it's
a
combination
for
me
of
ensuring
that
se
linux
is
on.
C
B
I
I
would
assert
that
se
linux
has
a
broader
range
of
capabilities
than
app
armor,
for
example
right,
so
the
isolation
and
the
protection
provided
by
sc
linux
is
key
and
again
that's
not
something
that
has
to
be
managed
at
the
kube
layer.
A
B
And
then
you
know:
how
do
you
audit
the
host
operating
system
again
it?
You
know
open
shift.
Four
works
with
rel
core
os,
which
is
a
container
optimized.
Os,
does
only
has
the
packages
needed
to
run
open
shift.
Audit
d
is
on
by
default,
but
important,
yeah
yeah
and
you
can
do
deeper
auditing,
and
so
some
of
those
partners
that
we
talked
about
earlier,
including
stackrock,
systig,
palo
aqua.
B
They
deploy
an
additional
capability
that
does
deeper
data
collection
and
and
some
of
the
solutions
do
correlation,
which
is
really
critical
for
a
container
environment
where
things
are
coming
and
going
right.
You
can't
just
that
that
process
that
was
running
a
few
minutes
ago
might
you
know,
might
have
died.
As
we
were
saying
earlier
right
and
you've
collected
data
on
that
process.
B
How
do
you
associate
that
with
the
name
of
a
deployed
pod
or
a
service,
so
that
you
know
you
know
what's
relevant
and
and
that
correlation
really
really
matters
and-
and
I'm
sorry
I
can't
say
much
about
debbie-
and
I
don't
know
if
that's
something
you
can
opine
on.
A
I
mean
debian
has
a
a
good
set
of
auditing
capabilities.
It's
you
know
it
to
me
the
difference
you
know
coming
from
my
you
know:
linux
admin
moving
into
red
hat
kind
of
area
right,
like
I've,
always
felt
like
sc.
Linux
has
always
been
there
for
me.
If
that
makes
sense
right
like
where
app
armor
is
a
little
newer.
A
You
know
I
I
remember
reading
about
sc
linux,
you
know
in
like
the
year
2000,
so
it's
been,
you
know
developed
rather
heavily
by
a
lot
of
people
at
this
point,
and
I
think
you
know
given
that
we're
on
a
red
hat
channel,
you
know
rail's,
probably
going
to
be
the
better
choice
for
everybody
in
my
opinion,
but
that's
just
my
opinion
right.
B
And
I'm
interested,
I
mean
it
looks.
I
just
did
a
quick
google
right,
so
there's
audit
d
also
available
with
debian
and-
and
I
think
what
we
also
start
to
hear
coming
up
more
often
is
conversations
around
ebpf
again
for
that
deeper
data
collection
right.
So
that's
definitely
a
space
red
hat
is,
is
you
know,
stack
rocks
is
already
there.
B
Red
hat
will
be
doing
investing
more
in
that
space,
and
so
you
know
when
it
comes
to
debian,
I'm
just
gonna,
google
again
and
see
pf
you
know
you
know
is:
is
that
already
part
of
a
debbie
and
distro
so
but
but
ebpf
is
is,
is
something
definitely
worth
looking
into.
A
Absolutely
and
I'm
trying
to
find,
I
know,
there's
an
ebpf
book
that
someone
sponsored
at
some
point
and
it's
free
somewhere,
but
I
can't
find
it
I'm
sorry,
but
there
are
a
lot
of
great
like
grin
brendan
gregg.
If
you
haven't
been
to
his
website,
definitely
recommend
you
check
out
brendan
grad's
website,
because
it
is
just
full
of
knowledge
on
all
things,
ebpf
and
he's
actually
written
a
book
about
it.
So
cool
that
link
in
there.
A
A
I'm
looking
at
it
like,
I
know
she,
I
know
she
wouldn't
tell
me
no.
I
typed
that
wrong
anyways,
so
yeah
ebpf
gives
you
like
a
deep
look
at
the
syscalls
and
everything
going
on
underneath
the
hood
kind
of
deal,
and
that
is,
if
you
want
to
do
a
lot
of
tooling
or
a
lot
of
tweaking,
that's
a
great
place
to
do
it.
So
you
know
we're
kind
of
wrapping
up
here.
We
only
got
about
seven
minutes
left.
A
B
Boy,
you
know,
I
I
think
really
it's.
I
can't
so
I
assume
that
there's
going
to
be
unknown
right,
that
there's.
B
Going
to
come
up
that
none
of
us
predicted
and
and
so
it's
not
so
much
the
the
unpredicted
that
keeps
me
up
it's
more.
You
know
the
organizations
that
haven't
yet
found
a
way
to
update
their
processes
to
at
least
do
the
basic.
That
kind
of
is
what
what
really
concerns
me
right.
They're
they're,
maybe
not
yet
structured
in
a
way
to
make
it
easy
to
update
vulnerable
packages
or
even
be
aware
that
they've
got
vulnerabilities
in
their
environment
they're
not
yet
doing
the
appropriate
level
of
security
for
identity
and
access
management.
B
A
Right
exactly
right,
it's,
why
are
you
still
using
string
to
hold
up
your
pants
there's
this
invention
called
a
belt
right?
It's
and
that,
to
be
honest
with
you,
it's
the
it's!
You
know
not
to
pull
a
full
don
rumsfeld
here,
but
like
there,
there
actually
is
unknown
unknowns
in
the
security
space,
they're
called
they're
called
zero
days.
C
A
A
What
do
you
as
far
as
misconceptions
about
devsecops?
What
do
you
think
are
some
of
the
the
misconceptions
people
have
about
it.
B
First,
they
they
think
that
they
can
just
add
a
tool
and
it
will
fix
everything
yeah,
that's
right,
yeah.
So
so,
even
though
I've
talked
a
lot
about
vulnerability
scanning
and
we've
talked
about
dependency,
analysis
tools
aren't
enough
right.
So
so
you
have
to
incent
your
team
to
you
have
to
give
them
time
to
respond
to
what
those
tools
tell
them
right
and,
and
it's
like
they're
in
you
know,
I've
been
in
organizations
where
developer
productivity
is
measured
by
the
number
of
lines
of
code
they
deliver.
Oh
god,.
B
B
Measure
them
on
how
quickly
they
can
respond,
do
do
things
like
that,
so
so,
and
you
know
or
or
how
many
tests
that
you
know
the
effectiveness
of
tests
right
also
are.
Are
you
testing
the
right
things?
B
You
know
it's,
it's
not
about
how
necessarily
how
quickly
again,
you
have
to
balance
the
speed
of
delivery
with
meeting
the
customer
goals
and
the
customer
goals
include
reasonable
expectation
of
security
right.
So
so
balance
those
two
and
you've
got
to
think
about.
How
do
you
help
because
people
respond
to
how
they're
measured
right
so
yeah.
A
A
Right
so,
let's
in
the
note
I
was
in
the
show
on
a
high
note,
you
know
you
work
here
at
red
hat
you're
you're
in
the
the
cloud
platforms
business
unit
like
I
am
you
know
what
gets
you
up
in
the
morning?
What
what?
What
motivates
you
to
come
in
and
work
for
red
hat
every
day.
B
Or
you
know
telco.
I
mean
there's
just
this
really
fascinating
set
of
problems
as
we
help
our
customers
move
into
a
more
cloud
native
world
and
and
we
get
to
be
there
working
with
them
on
the
forefront
and
figuring
it
out
and
and
helping
them
on
that
journey.
And
it's
a
great
deal
of
fun.
And
we
have
it's
such
a
great
group
of
people
to
work
with
too
so.
A
Oh
no
last
question
and
then
we're
going
to
wrap
it
up.
Do
you
think
there's
a
lack
of
qualified
professionals
in
the
devsecop
arena,
certainly.
B
B
A
Well,
thank
you
so
much
for
joining
us
today
kirsten
this
has
been
a
wonderful
episode
and
a
lot
of
great
conversation
in
chat
and
things
that
we
shared
with
everybody.
So
I
really
appreciate
you
coming
on
today
and
thank.
B
A
Thank
you,
everybody
in
the
audience
for
watching
and
participating,
and
we
will
see
you
again
here
in
there's
some
stuff
coming
up.
So
it'll
be
a
couple
few
more
weeks
for
the
next
in
the
clouds
episode
but
later
on
the
channel.
Today
we
will
be
talking
about
clear,
four
and
container
scanning
yeah,
like
that.
It's
going
to
be
an
awesome
episode.
It's
actually
the
series
premiere
of
cloud
native
thursdays
here
on
openshift
tv
and
that'll,
be
at
1
pm
eastern
1800
utc
so
come
check.
It.