►
From YouTube: OCB TF: DevSecOps: What Comes first the Tools or the Culture - Kirsten Newcomer (Red Hat)
Description
Adoption of cloud native solutions creates a stronger push for DevOps and DevSecOps. Workloads are ephemeral; Traditional security tools often don’t work for cloud native technologies; security needs to be built in; apps need to be “born” secure; security needs to shift left in the lifecycle. All of this requires change. The question is: how do you make this shift successfully? And what comes first -- changing your tools or changing your culture?
A
Well,
hello,
everybody
and
welcome
again
to
another
openshift
commons
briefing
today,
as
we
like
to
do
on
fridays,
we're
going
to
talk
about
cultural,
organizational,
transformational,
topics
and
securities
high
on
everybody's
list,
and
we
have
with
us
today
the
director
of
cloud
and
devsecops
strategy
for
the
cloud
platforms
group
kirsten
newcomer
who's,
going
to
walk
us
through
a
conversation
about
devsec
ops
and
what
comes
first,
the
tools
or
the
culture,
and
you
can
ask
questions
if
this
is
meant
to
be
an
interactive
thing.
So
she's
going
to
talk
for
a
little
bit.
A
B
B
So
just
as
an
introduction
right,
you
know
this
is
this
is
I
think,
relatively
well
understood
at
this
point
that
businesses
need
the
ability
to
innovate
faster
in
order
to
differentiate
themselves.
I.T
departments
need
the
ability
to
deliver
those
different
differentiated
applications
faster
and
in
the
cloud
native
world
right.
That's
containers,
kubernetes
microservices,
but
also
devops,
is
a
key
enabler
for
delivering
and
innovating
more
quickly
and
that's
across
a
wide
variety
of
markets
and
a
wide
variety
of
of
focus.
B
Application
focus
right,
not
just
you
know,
cloud
native
micro
service
based
apps,
but
ai
and
machine
learning,
right
and
internet
of
things.
How
do
you
make
good
use
of
the
data
data
lakes?
All
of
these
kinds
of
things
really
matter
and
I'd
say
they
matter
even
more
with
the
pandemic
that
changes
the
pandemic
have
have
kind
of
imposed
on
the
economy
right,
everybody
is
doing
more
business
in
a
digital
fashion,
and
so
why
is
devops
a
key
part
of
delivering
more
quickly,
agility
and
innovation
by
the
way
agility
really
can't
succeed
in
silos
right?
B
So
if
you
haven't
run
across
the
term
before
which
I
imagine
is
not
the
case
with
this
group
right,
these
are
they're,
keep
three
key
elements
that
make
devops
work.
I'm
not
going
to
read
this
slide
to
you.
Culture
is
key
automation
and
technology,
and
I've
talked
with
a
lot
of
different
folks
about
the
which
comes
first
thing
right.
Do
you
you
know
what's
most
important,
do
you
need
the
tools
that
enable
devops?
B
B
A
So
I
think
the
way
that
we
could
do
this
is
if
you,
if
you're
listening
in
here,
all
the
folks
who
here,
if
you
have
an
opinion,
just
raise
your
hand
in
the
chat,
and
I
can
turn
you
on
your
video
or
your
voice.
And
let
you
speak
if
you'd
like
to
there
and
add
that
in
or
we
can
do
the
talking
at
the
end,
which
might
be
easier
go.
B
For
that,
well,
let's
yep
we'll
go
for
that,
so
so
the
short
version
of
devops
right,
it's
all
about
getting
things
out
the
door
quickly
to
your
end
users
and
reliably.
But
we
can't
forget
the
security
piece
and
the
reason
I
like
to
use
the
phrase.
Devsecops
is
because
it
just
calls
it
out
directly
and-
and
it
adds
explicitly
to
that
tldr-
that
getting
the
things
out
the
door,
the
solutions
out
the
door
securely
is
key.
B
So
when
we
think
about
tools
and
cultures,
you
know
one
of
the
things
we
do
see
at
times
is
people
start
adopting
devops
without
necessarily
making
significant
changes
to
those
silos
right.
A
devops
team
often
becomes
a
part
of
the
app
dev
team,
an
extension
of
the
app
dev
team,
rather
than
a
real
combination
of
app
dev
ops
and
the
security
teams.
B
Apologies
for
the
background
noise,
and
so
we
see
at
times
right
that
that
that
still,
that
kind
of
wall
between
app
dev
and
ops
still
can
kind
of
sometimes
be
there
when
we're
talking
about
the
the
devops
team
and-
and
so
unfortunately,
that
can
lead
to
a
behavior.
Where
there's
an
example
of
a
single
team
of
engineers,
thinking
that
they
can
solve
the
full
organization's
technology
problems
just
by
using
orchestration
tools
right
just
by
using
the
cicd
tooling,.
B
B
The
supply
chain
is
clearly
a
new
element.
You
know
it's
always
been
an
element
of
the
threat
landscape,
but
it's
got
new
prominence
these
days
when
you're
working
in
the
public
cloud,
you
have
a
shared
responsibility
model.
But
honestly,
even
when
you're
working
on
premises,
you
still
have
a
shared
responsibility
model.
Your
app
dev
team,
your
ops
team,
your
security,
your
network
team,
as
people
move
to
containers
and
kubernetes.
B
So
we're
seeing
more
and
more
of
a
recognition
that
to
secure
cloud-native
workloads,
which
are
frequently
ephemeral,
they
may
only
run
for
five
minutes.
They
may
run
for
longer.
They
may
run
for
less
if
one
of
those
instances
of
a
cloud
native
workload
goes
down
in
an
open
shift
or
a
cube
environment,
kubernetes
is
going
to
spin
up
a
new
instance
from
the
image.
So
that
means
that
you
really
can't
rely
on
some
of
the
traditional
approaches
to
going
in
and
having
a
human,
patch
and
environment
when
a
new
vulnerability
is
discovered
right.
B
B
B
B
B
You
know
where
somebody
says:
thou
shalt
and
somebody
else
says
we
can't
and
here's
why
and
you
know
so
so,
having
the
what's
the
use
case,
we're
trying
to
address
together
help
the
business,
be
successful,
minimize
risk
and
you
know,
deliver
solutions
faster,
so
the
characteristics
that
help
make
this
kind
of
change,
successful,
open
communication,
respect
developing
trust
across
those
silos.
That's
key
incentive
matters
too
right
how
people
people
do
respond
to
how
they're
measured
and
so,
if
you're,
primarily
measured.
B
If
a
developer
is
primarily
measured
on
the
the
number
of
lines
of
code
they
deliver,
that
may
not
be
the
best
measurement
you
know
might
also
want
to
be.
Looking
at.
You
know
how
quickly
do
they
respond
to
newly
found
vulnerabilities?
Not
so
much
is
it
vulnerability-free
code,
because
that
can
be
challenging.
New
vulnerabilities
are
discovered
in
existing
code
all
the
time,
but
maybe
the
measured
better
measurement
is
how
quickly
can
the
team
as
a
whole
get
an
update
to
that
newly
discovered
vulnerability
and
get
that
code?
B
Rebuilt
and
redeployed
give
team
members
responsibility,
push
responsibility
down
the
chain
so
that
individuals
feel
that
they
can
make
a
difference
and
then,
finally,
you
really
have
to
be
comfortable
with
experimenting
and
knowing
that
some
things
are
going
to
fail,
and
you
want
to
iterate
to
improve
those
failures
and
patience.
Patience,
of
course
is
key,
and
then
the
teams
who
are
really
successful
in
taking
on
these
kinds
of
things
this
this
kind
of
this,
this
degree
of
change
they
do
that
with
executive
sponsorship.
B
You
know
publicize,
what's
happened
so
when
you
think
about
you
know
some
of
the
elements
of
containers
and
kubernetes
right.
There
are
some
key
areas
to
think
about.
Regarding
security,
how
do
I
detect
problems
early
in
the
life
cycle?
What
does
it
mean
to
shift
security
left?
What
do
I
need
to
do
in
the
build
environment?
Some
of
the
best
practices
here
start
with
trusted
content.
Make
sure
you
use
a
container
registry
to
store
any
content.
You
pull
down
from
externally
put
security
gates
into
your
build
management
process
and
into
your
ci
cd
pipeline.
B
B
You
want
to
protect
the
runtime
as
much
as
possible.
You
want
to
collect
a
lot
of
data.
You
want
good
observability
about
your
running
environment
so
that
you
can
use
that
to
notice
anomalies
and
to
respond
to
those.
Of
course,
you
need
to
protect
your
application,
access
and
and
data
as
well
and
in
a
kubernetes
environment.
You
want
to
use
network
micro
segmentation
to
isolate
running
workloads
as
well
as
take
advantage
of
things
built
into
linux,
such
as
se,
linux
to
mitigate
or
prevent
runtime
escapes.
B
A
Let
me
just
ask
a
quick
question
too,
because
I
you've
hit
on
a
number
of
key
things
from
from
my
point
of
view,
and
and
one
of
them
you
talked
about
doing
a
poc
first
and
getting
that.
How
do
you
get
from?
How
do
you
coach
people
to
get
from
poc
to
a
repeatable
pattern
so
like
they
do
it
once
you
know,
is:
is
there
something
in
the
coaching
that
you
give
when
you're
talking
with
you
know
our
customers
and
other
folks
about
this.
B
I
I
think
I
think
that
really
comes
back
to
iterating,
so
so,
and
I
would
use
the
term
pilot
rather
than
a
poc.
So
I
I
think
it's
it's
important
to
pick
something
that
is
an
actual
project
that
your
team
needs
to
deliver
and
and
so
you're
gonna
pilot,
this
new
process
on
something
that
you
actually
need
to
make
available
to
your
end.
B
Users
and
and
therefore-
and
maybe
you
build
a
little
extra
time
into
that
pilot-
to
acknowledge
that
you're
gonna
have
to
do
some
iteration
you're
gonna
be
making
some
changes
as
you
go
and-
and
you
also
need
to
be
sure
that
there's
executive
sponsorship,
but
but
the
goal
is
that
you
are
going
to
define
processes
and
refine
those
processes
using
an
actual
project
so
that
you
know
normally
it's
very
unusual
that
you
would
deliver
once
right.
You're
gonna
have
a
new
version
of
that
same
app,
another
time
down
the
road.
B
A
B
They
usually
rely
on
the
technical
expertise
of
the
security
team
or
sometimes
the
the
active
teams
themselves,
and
I
think
that's
a
lot
of
what
leads
to
kind
of
the
the
the
frustration
in
the
communication
is
that
these
groups
aren't
necessarily
talking
the
same
language
yeah,
so
I'd
prioritize
connecting
in
the
security
team
first,
because
they
often
do
represent
compliance
and
they're,
usually
more.
You
know,
they're,
usually
a
little
deeper
in
the
technology
and
they're,
therefore
better
positioned
to
have
that
back
and
forth
conversation.
B
B
So
as
you're
thinking
about
your
processes
and
your
tools,
keep
in
mind
that
you
do
have
a
compliance
team
that
needs
output
in
a
form
that
they
can
take
to
an
auditor,
whether
that's
arf
or
json,
or
whatever.
The
format
is
that
they're
expecting
to
get
that
data
in
and
think
about,
and
look
for
automated
tools
that
can
help.
You
demonstrate
that
compliance
in
a
way
that
reduces
the
effort
for
everybody.
C
A
But
the
other
piece
of
the
puzzle
is
like
how
how
do
you
tell
people
that
you've
done
it?
You
know,
like
you
measure
that
it's
done
in
a
way,
that's
tangible
or
yeah,
and
I
know
I'm
hooked
on
the
audit
side
of
things
so
and
auditable
and
that's
always
been
the
interesting
conversation
that
I've
ended
up.
A
Having
with
people
is
that
yeah
developers
get
it
systems
get
it,
and
usually
we
can
talk
the
the
c-level
people
into
it,
and
then
everybody
forgets
to
talk
to
the
compliance
and
risk
officers,
and
then
then
there
comes
this
grinding
halt
like
well.
You
can't
deploy
that
until
I
have
this,
you
know
and
that
that's
that's
what
I'm
getting
at
is
that
that's
the
and
that's
a
cultural
shift.
That's
like,
including
you
know
the
entire
and
collaborating
across
the
silos
that
you
mentioned
and
making
that
something.
B
C
B
C
B
They
and
and
when
we
come
back
to
measurements,
I
mean
there's,
there's
two
elements
of
measurements:
there's
there's
like
how
do
you
measure
what's
happening
in
the
in
the
pipeline,
which
is
almost
the
devsec
piece
of
things
and
then
how
do
you
measure
what's
in
the
secops
area?
And
and
so
you
know,
a
measurement
can
be
yes
and-
and
this
actually
applies
to
a
process
piece
for
compliance
officers
right.
Yes,
we
run
vulnerability
scanners
on
our
private
registry
at
this
interval,
and
I
can
show
you
dated
reports
demonstrating.
B
It
involves
process
as
well
right.
So
so,
as
you
kind
of
define
your
processes,
you
want
to
document
them
and
as
they
change,
you
want
to
update
that
documentation,
and
that
can
be
a
hard
thing
to
do.
But
back
to
your
point
about
auditing,
because
we
need
to
audit
the
platform
for
technical
controls,
we
need
to
audit
our
processes
to
ensure
they're
compliant.
B
One
of
the
really
nice
things
about
doing
everything
as
code
is
that
you
get
audit
trails
of
who
did
what
and
when
something
changed,
and
so
maybe
part
of
what
you
know
would
really
help.
The
compliance
team
and
the
auditors
is
helping
them
understand
how
to
view
that
audit
data,
both
through
the
pipeline
and
the
audit
data
that
you
might
produce
for
technical
controls
on
the
platform
itself
and
and
giving
them
a
way
to
kind
of
check
it
for
themselves.
A
B
Well,
well,
and
more
often,
the
way
an
audit
trail
is
created
in
that
scenario,
right
for
a
traditional
architecture
is
I've
got
a
change
management
system,
something
like
servicenow,
a
request
gets
logged,
so
an
alert.
You
know
somebody
says
new
vulnerability,
alert,
get
sent,
a
change
request,
gets
logged,
saying
please
patch
this
vulnerability,
and
then
somebody
has
to
you
know
that
gets
handed
off
to
the
appropriate
team
and
they
have
to
schedule
all
of
that
and
and
then
so.
B
Your
auditability
relies
on
people
kind
of
passing
along
this
change
request
in
an
automated
ci
cd
pipeline
for
an
application
or
for
the
platform
itself
right.
You
have
processes
in
place.
You
can
have
automated
triggers
that
say:
hey
there's
this
new
vulnerability
discovered
in
one
of
the
images
you're
using
I'm
going
to
automatically
pull
down
the
latest
version.
That
has
that
fix,
and
I
can
automatically
kick
off
a
rebuild
of
that
application
with
that
fixed
base
image,
and
then
you
might
have
gates
around
deployment
right.
B
You
need
to
be
sure,
you've
tested
it,
you
want
it,
you
don't
you
don't
want
to
just
rebuild
and
redeploy,
but
you
can
automate
a
lot
of
those
gates
and
then,
if
it's
for
the
platform,
you
can
do
something
similar,
because
you
know
a
platform
like
openshift
allows
you
to
apply
the
you
know
patches
in
a
rolling
fashion
across
the
cluster,
with
zero
app
down
time
for
well-behaving
apps.
Now
some
orgs
are
going
to
want
to
schedule
those
patches
anyway
right,
but
you
can
still
use
automation
to
do
that.
Scheduling.
B
So,
whether
that's
an
alpine
base
image,
a
rel
ubi
base
image,
you
want
to
be
sure
that
you
are
using
content
that
you
have
a
trusted
source
for
you
can
verify
where
it
came
from.
You
can
and
ideally
also
that
it's
a
source
that
regularly
updates
their
content,
so
that
if
a
new
vulnerability
is
discovered,
you
have
easy
access
to
it
to
a
fix
to
that
vulnerability.
B
Security
gates
in
your
pipeline
can
can
and
should
include
vulnerability
scanning,
but
an
emerging
area.
That's
really
become
more
and
more
important.
Is
application
config
analysis
any
solution,
any
pod
app.
You
know,
containerized
app,
that
you're
deploying
to
a
cube
environment
has
a
lot
of
config
data
that
goes
with
it,
and
so
you
want
to
be
looking
for
things
like.
Are
there
embedded
secrets
in
the
image,
but
you
also
want
to
be
looking
at
what
what
security
requests
are
being
made?
B
You
know
we
have
a
number
of,
even
even
though
openshift
4
itself
is
highly
automated-
supports
automated
operations
with
kubernetes
operators.
We
also
have
customers
who
ensure
that
every
part
of
a
platform
deployment
is
managed
in
an
automated
fashion.
Through
a
platform
pipeline
so
that
again
it's
auditable
and
they
can
verify
that
everything
is
deployed
in
the
way
they
intended
it
to
be
deployed.
B
Furthermore,
this
really
sets
you
up
for
just
just
like
containerized
image
applications.
You
should
think
of
them
as
ephemeral,
and
you
can
always
be
redeploying
from
an
image.
You
should
be
able
to
think
about
your
cluster
that
way
right.
You
should
be
able
to
tear
down
and
replace
your
cluster
at
any
point
in
time,
and
automation
makes
that
possible.
B
Automated
compliance
and
automated
audit
are
are
really
key
things
and
there's.
There
are
plenty
of
solutions
out
there
available
to
you
again
automate
the
life
cycle.
We
kind
of
hit
on
this.
So
let's
talk
a
little
bit
about
managing
the
deployment
once
you've
got
your
cluster
up
and
running.
You've
got
it
configured
the
way
you
expect
you're
you're
all
set
up
for
managing
updates
to
that
cluster.
B
Again,
we
want
to
use
a
getups
and,
or
and
or
argo
cd
approach
to
that
deployment,
continuous
deployment
piece.
You
want
to
take
advantage
of
kubernetes
admission
controllers
to
ensure,
ideally,
you
found
any.
You
know:
requests
for
excess
privileges
early
in
the
life
cycle
through
doing
app,
config
analysis.
But
again,
so
that's
your
belt.
B
You
need
your
suspenders,
so
something
slips
through
something
didn't
get
vetted
use,
pod
security
policies
or
openshift
security
context
constraints
to
prevent
admission
of
pods
that
have
privileges
that
you
don't
want
to
allow
on
your
cluster,
validate
image
signatures,
leverage,
something
for
your
apps,
like
service
mesh,
to
add
an
additional
layer
of
protection
for
application,
traffic
and,
of
course,
continuously
monitor
for
new
vulnerabilities
and
be
prepared
always
to
re,
build
and
redeploy,
not
just
your
apps,
but
your
platform
as
well
and
again
when
it
comes
to
getting
started.
You
know
start
with
a
pilot.
B
A
Well,
awesome,
and,
and
and
and
that's
really,
I
think,
culturally
and
technology
like
I
tend
to
focus
on
you-
know,
argo
cd
or
cube
linter,
or
you
know
that
goes
straight
to
the
technology.
So
it's
really
nice
to
have
a
conversation
about
the
cultural
pieces
of
this
and
culturally
for
security
teams.
This
concept
of
experimentation
and
allowing
for
failure
is,
is
I
probably
one
of
the
the
highest
bars
to
you
know
mentally
get
through
like
that's.
A
B
Yeah,
no,
that's.
Definitely
that's
that's
a
really
valid
point.
I
think
security
teams
are.
Are,
you
know,
used
to
trying
to
again
really
their
job
is
to
minimize
risk.
There
is
no
such
thing
as
zero
risk,
but
sometimes
they
get
this
mindset
that
there
has
to
be
zero
risk
and
so
kind
of
oftentimes.
You
need
executive
support
to
shift
that
mindset,
but
another
way
that
that
the
technology
enables
a
change
in
the
mindset,
because
containers
are
the
same
from
dev
to
test
to
production.
B
If
you
set
up
your
environment,
your
you
know,
if
you're
you're
deploying
to
a
coupe
cluster,
it's
the
same
container
image
deployed
to
coop
cluster,
whether
it's
dev
test
or
production.
If
you
set
it
up
so
that
you
know
you're
really
doing
that
testing
in
exactly
the
same
kind
of
environment
as
your
production
environment,
then
you
can
maybe
get
your
security
team
a
little
bit
more
comfortable
with
the
idea
of
iterating.
B
And
ideally,
you
know
if
there's
going
to
be
a
failure,
it's
going
to
show
up
in
the
test
environment
as
long
as
you've
got
the
right
tools
in
place
and
because
clusters
can
be
spun
up
and
shut
down
so
easily.
I
think
it
makes
it
simpler
than
a
traditional
architecture
where
you
know
vms
might
be
scarce.
You'd
have
to
it
would
take
weeks
to
get
a
vm.
You
know
you'd
have
to
request
it
vm.
It
would
take
weeks
to
get
it
provisioned.
B
The
vm
environment
is
different
from
test
and
and
production,
and
so
the
closer
you
can
get
these
environments
to
be
exactly
the
same
use
the
same
tooling,
the
same
security,
tooling,
the
same
network
policies,
the
same
configs,
the
better
your
chances
of
finding
something
early
and
giving
some
comfort
to
those
security.
Folks
who
are
so
worried
right
that
that
you
know
their
job
is
to
prevent
the
company
from
showing
up
in
the
newspaper.
A
A
You
know
is
that
you
know
previously,
you
would
do
development
on
your
local
machine,
throw
it
over
to
test
and
qa
and
all
of
this-
and
you
know,
we've
now
had
like
seven
or
eight
years
of
this
containerization
stuff,
but
I
also
think
that
you
and
I
we're
at
red
hat
we're
at
the
bleeding
edge
of
of
the
knife
right.
You
know
so
we
we
drink
this
kool-aid
all
the
time
and
I
and
we
kind
of
have
to
realize
that
not
everybody
has
followed
this
path
as
as
quickly
as
as
others.
B
Learning
from
that
and
expanding
it
across
the
larger
organization
is
a
win
too,
and
and
it's
funny
what
you
were
talking
about
with
with
the
past
I
mean
I
remember,
gosh,
oh
well,
over
maybe
15
years
ago
now
you
know
this
this
goal
at
a
company.
I
was
working
at
to
be
able
to
more
easily
right.
You
find
a
problem
in
production.
B
How
do
I
trace
back
from
that
production
code
to
the
root
cause
the
source
code
problem,
that
in
a
development
environment,
so
that
I
can
more
easily
reproduce
and
fix
and
and
get
that
fix
back
into
production?
And
there
were
all
sorts
of
different
kind
of
ideas
about
how
to
do
this
and
how
data
sharing?
And
how
do
you
get
traceability
from
the
source
code
to
the
binary
and
we're
in
a
world
where
less
of
that
matters,
because
it's
the
same
image
from
dev
to
test
to
production?
A
Of
cool,
so
we
do
have
a
question
from
jake
in
the
chat
here
and
I
think
it's
he'd
rather
stay
off
camera.
So
that's,
okay,
my
hair
is
doing
okay.
Today,
do
you
see
security
teams
being
spread
thin
in
devops
teams
and,
if
so,
does
training
developers
on
basic
security
coding
practices
become
a
priority
like?
How
do
you
spread
the
load
kind
of.
B
It's
a
great
question:
I
mean
that
the
truth
is
that
security
folks
are
security,
skills
are
thin
on
the
ground
period
and
and
they're
expensive,
and
so
the
more
an
organization
can
do
to
help
all
members
of
the
team
understand
what
the
security
goals
are
and
again
the
why
behind
them,
because
the
technology
does
change,
and
so
you
know
there
are.
There
are
scenarios
where
something
like
saying
you
know:
every
certificate
has
to
be
signed
by
the
corporate
ca.
B
There
may
be
cases
where
that's
appropriate
and
there
may
be
cases
where
that's
less
appropriate
in
a
in
a
cube
cluster.
You
know,
maybe
the
platform
certs
don't
need
to
be
signed
by
the
corporate
ca,
because
that
cluster
is
a
closed
route
of
trust,
but
you
want
your
application
cert
signed,
but
you
need
to
have
conversation
about
that.
B
So
so
one
thing
we
I
haven't
heard
as
much
about
this
recently,
but
a
few
years
back,
I
started
hearing
you
know
about
roles
called
like
the
beso
role,
the
business
information,
security
officer
who
was
embedded
with
app
dev
teams
and
because
they
were
embedded,
they
could
have
conversations
about
risk
and
the
developers
could
have
a
conversation
about
well,
we
we
don't,
you
know
doing
it.
This
way
is
a
problem,
but
what
if
we
did
it?
This
other
way?
B
B
A
A
B
Sure,
well,
I
think
again,
some
of
this
is
is
due
to
change
in
technology
right.
It
used
to
be
that
you
know
so.
The
developers
responsible
for
doing
you
know
kind
of
building
their
code
and
and
and
doing
doing,
testing
in
a
test
environment
and
there's
a
certain
set
of
configs
that
they
know
they
need,
but
in
production
right
it
was
always
the
ops
team,
the
developers
would
say.
B
Well,
here's
how
I
need
my
my
vm
configured
it
needs
to
have
these
system
depend
these
system,
libraries
and
it
needs
to
have
these
ports
available,
and
you
know
it
kind
of
boom
boom
boom
boom.
Everything
would
be
listed
out
and
handed
off
to
ops,
and
then
you
know
the
ops
team
would
have
an
opportunity
to
kind
of
determine
whether
it
met
their
concerns
and
the
security
team
too
networking
team
and
now
all
that
configuration
in
a
in
a
containers
and
coop
world.
All
that
config
data
is
is
in
my
deployment.
B
It's
in
my
cube
deployment.
It's
in
my
pod.
In
my
you
know
what
user
I
want
to
run
at
what
linux
capabilities
I
might
need
you
know
what
what
are
my
network
connections?
That's
all
going
to
be
in
the
sdn,
it's
all
less
visible
to
the
ops
and
network
and
security
teams,
because
it's
all
configuration
as
code
for
the
application,
and
so
one
of
the
ways
you
win.
Trust
is
by
using
that
automation,
those
those
newer
automation
tools
to
analyze
for
challenges,
whether
it's
a
helm
chart
a
deployment.
B
You
know
config
something
in
yaml
image,
run
those
analysis
tools.
Looking
it's
also
a
way
to
educate
your
developers
about,
what's,
okay,
to
do
and
and
what
causes
problems
to
run
those
analysis
tools,
early
share,
the
output
of
them
provides.
You
know,
visibility
across
the
team
and
it
reduces
problems
early
in
the
life
cycle.
A
I
just
like
yam
all
this
and
yeah
that,
like
everything
every
time
and
the
access
to
the
config
files
and
the
yaml
and
the
helm,
charts
and
stuff,
you
know
we,
we
have
access
to
tweak
that
yeah
yeah.
Chris
is
joking
about
calendar
driven
yaml
engineers.
Oh
no!
Creating
these
things.
Yes,
it's
quite
it
is
it's
like
for
me
that
that
that
is
the
you
know
the
part
that
was
when
I
was
back
in
the
day
when
I
was
writing
applications
and
deploying
them.
That
was
the
mystery
part
like.
A
I
would
have
it
configured
perfectly
for
my
thing
and
now
like
I,
I
go
into
ides
and
things
like
that
and
I
I
have
access
to
to
tweak
it
again
and
so
what
this
automation
layer
to
get
to
the
deployment
you
know
you
can
tweak
it
having
that
automation
in
the
ci
cd
check
it
before
it
goes
into.
Production
is
really
kind
of
key,
and
it
has
really
made
me
a
better
developer.
A
B
I
don't
know
I
don't
know,
maybe
maybe
we
should
write
one
we
we
do
have.
We
do
have
some
folks
in
red
hat,
who
have
put
together
what
they
might
call
would
be
the
you
know,
a
container
factory
that
that
outlines
we
can.
We
can
dig
up
a
link
to
something
like
that
and
share
it.
I'm
not
sure
whether
it's
in
a
blog
or
whether.
B
C
C
A
B
A
C
A
A
For
it
and
upgraded
recently-
and
I
will
add
this
caroline-
I
will
add
the
slides
I'll-
take
this
whole
talk,
which
thank
you
so
much
for
spending
the
time
with
us
today
to
talk
about
this.
Next
week
we
have
problemistic
versus
deterministic
security
with
steven
gear.
I
think
that's
how
you
gear
you
gigger,
or
something
like
that
from
stack
rocks
is
going
to
be
talking
same
time
next
week.
A
So
if
you
want
to
join
us
in
the
following
week,
after
that,
john
willis
is
going
to
be
talking
again
on
devsecops,
so
we've
got
three
strikes
and
you'd
better
watch
them
all
and
we'll
hopefully
hit
it
out
of
the
park,
and
I
think
you
have
done
that
today.
So
thank
you
so
much
for
taking
the
time
kirsten
and
we'll
keep
you
in
on
online
a
lot.
I
think,
in
the
coming
future
with
all
of
the
security
stuff.
That's
coming
down
the
pike.
So
thanks
again.