►
From YouTube: In the Clouds (S2 E8) | DevSecOps and Shift Left Part 2
Description
What exactly is Shift Left? How does it apply in the context of DevOps? Shift left is a term that comes up a lot when talking about IT security and DevSecOps - and for good reason. But what does it mean? And how can corporate leaders understand it in the context of their organization? Join Chris Short, Kirsten Newcomer and Jamie Scott for part two of our discussion about shifting left and DevSecOps. Don't miss this episode to learn what we mean by shift left, what it looks like in the real world and how we can incorporate a culture of continuous improvement into both software and corporate culture.
About In The Clouds:
Red Hat’s senior leadership is having to execute at an ever-increasing pace. That means that today's technology decisions have to balance short-term risk with long-term gains. This unique series provides host Chris Short inviting thoughtful and candid discussions with each guest.
Follow us:
Chris Short https://twitter.com/chrisshort
OpenShift https://twitter.com/openshift
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_c...
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com http://red.ht/3nJ6AKX
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com http://red.ht/34xQoER
#RedHat #OpenShift #Kubernetes
A
A
Good
morning
good
afternoon
good
evening
and
welcome
to
a
very
special
episode
of
in
the
clouds
here
on
red
hat
live
streaming.
I
am
chris
short
host
and
showrunner
of
red
hat
live
streaming.
I'm
joined
by
a
few
of
my
favorite
fellow
red
hatters,
kirsten
newcomer,
andrew
clay,
shafer
and
jamie
scott.
Today,
we're
talking
about
devsicops,
shifting
left
and
all
things
you
know
security
from
a
holistic
perspective.
A
So
we
did.
This
is
part
two
of
the
series
we
did
part
one
on
the
level
up
hour
and
I'm
gonna
grab.
The
link
to
that
kirsten
was
so
nice
to
join
us
during
a
session
for
the
level
up
hour.
So
thank
you
for
doing
that
kirsten.
But
you
know,
while
I'm
doing
that,
let's
debate
if
cheesecake
is
a
cake
or
a
pie,
and
I
think
andrew
had
one
of
the
better
answers
in
the
pre-show
run-up
to
this.
I
feel
like.
B
C
A
B
A
C
A
B
So
I
think
there
was
always
a
security
theme
in
a
lot
of
the
devops
movement,
a
lot
of
the
devops
people,
but
that
that
explicit
invitation
is
nice
and
then
another
thing
I
think
is
worth
pointing
out
is-
and
this
is
related
to
the
transition
in
the
practices
of
operations.
Also
in
the
practice
of
security,
is
that
the
practices
are
not
are
not
standing
still
and
what
looks
like
you
know,
and
we
saw
this
trend
with
operations.
We're
going
to
see
this
trend
with.
Basically
everything
software's
eating
the
world.
B
If
you
will
that
operational
practice
became
more
and
more
about
writing
apis
writing
this
code.
That
did
all
this
work
right,
infrastructures,
code
and
you're,
starting
to
see
the
same
type
of
work
where
a
security
professional
in
in
2021
needs
to
have
like
some
understanding
of
code
needs
to
be
able
to
express
some
of
the
policies,
some
of
the
practices
as
code
and
so
there's,
there's
actual
there's
the
dev
part
of
the
developers
making
product
but
there's
also
the
dev
part
of
security
professionals
contributing
to
that
outcome.
C
Absolutely
and-
and
I
think
that's
a
place-
I'd
also
be
interested
to
hear
from
jamie
about
this,
because
he-
and
I
talk
a
lot
like
if
you
look
at
at
kind
of
the
some
of
the
tooling
that
supports
this.
This
shift
and
you
kind
of
think
about
a
typical.
I
don't
know
if
there
is
such
a
thing
as
a
typical
security
engineer,
but
security
teams
in
a
lot
of
enterprise
organizations
today
they
historically
have
not
needed
to
be
familiar
with
the
cicd
process.
C
A
C
Their
chief
of
cyber
security
decided
that
he
was
going
to
require
his
security
engineers
to
learn
the
cicd
process
and
to
learn
things
like
yaml
in
order
to
kind
of
contribute
and
participate
in
that
devsecops
pipeline.
And-
and
so
I
you
know,
it's
not
a
we're
not
allowed
to
share
their
name,
but
there's
actually
this
great
youtube
video
out
there
of
them
talking
about
so
they
kind
of
outed
themselves,
but
of
the
organization
talking
about
how
they
tackled
this
transition,
but
but
jamie.
D
Yeah,
so
to
me
shift
left
is
a
strategic
business
decision
that
starts
with
culture,
but
the
end
goal
is
not
necessarily
to
the
end.
Goal
is
to
reduce
cost
while
maintaining
the
compliance,
because
at
the
end
of
the
day,
security
has
traditionally
been
an
expense
center
in
order
to
meet
new
revenue
goals
and
break
into
decreased
sales
cycles.
D
And,
ultimately,
as
you
begin
to
look
at
devstec
ops
as
a
whole,
you
see
that
security
has
a
huge
opportunity
to
contribute
to
the
bottom
line
and
when
you
look
at
it
from
that
perspective,
you
see
that
by
reducing
the
cost
of
testing
by
shifting
left,
you
can
fix
bugs
more
effectively.
You
can
plan
you
can
make
prioritization
decisions
in
order
to
not
bolt
things
on,
and
I've
practiced
this
for
years.
At
this
point
and
what
we
really
see
is
it
starts
with
culture
and
what
you
were
saying
about
security
engineers
being
a
committer.
B
B
And
so
like
there's
this
there's
this
other
thing
I
think.
Maybe
this
is
the
setup
for
the
the
cheesecake
conversation,
but
security
is
not
one
thing
true
right
when
you
think
about
security,
what
security
professionals
do
in
organizations-
and
you
know
I've-
seen
different
versions
of
this,
but
you
could
probably
break
it
down
in
like
15
different
types
of
activities,
responsibilities
depending
on
the
maturity
depending
on
the
rigor.
C
Yeah
and-
and
I
think
compliance
teams
like
or
one
pattern
I've
observed
right
is
that
compliance
and
risk
people
have
or
or
in
particular
compliance
but
they've
they've,
provided
these
guidelines
based
on
known
traditional,
architectures
and
and
kind
of
the
ways
applications
worked.
You
know
pre-containers
pre-kubernetes,
pre-cloud
and
oftentimes
the
security,
the
people
responsible
for
implementing
those
things
don't
know
the.
Why?
Behind
the
requirement,
they
just
know
that
they've
been
given
a
requirement
and-
and
that
makes
it
hard
to
change
as
well.
C
B
And
you
end
up
where-
and
this
is
sort
of
the
point
I
think
james
is
making
me
ago
that
it's
it's,
this
academic
rubber
stamp
after
the
fact,
with
an
audit
that
oh,
we
check
these
boxes,
we're
in
compliance,
there's
lots
of
blurry
things
where
oh
are
we
in
compliance?
Well,
we'll
we'll
just
sign
off
on
it,
because
it's
like
you
know,
10
000
lines
of
code
or
whatever
and
then
and
then
we'll
go
we'll
just
we'll
figure
it
out
later,
but
there's
lots
of.
B
I
I
mean
this
is
the
this
is
the
beautiful
thing
about
where
some
of
this
is
going.
Is
that
you
can?
You
can
actually
be
in
compliance
verified
audited
in
a
way
that
you
never
could
before,
as
you
start
to
modernize
the
the
policy
and
have
the
policy
be
enforced
by
this
code
itself
instead
of
by
a
human?
You
know
checklist
audit.
After
the
fact.
D
D
D
So
there's
no
point
in
upgrading
them,
but
these
risks
still
need
to
be
accepted,
but
there
is
no
risk
so
the
ability
to
apply
that
mindset
in
an
automated
fashion
and
bridge
that
gap
between
of
the
y's
is
really
the
core
concept
here
of
you
have
product
managers
who
don't
understand
security
and
they're
responsible
for
the.
Why?
Typically,
you
need
a
champion
to
be
responsible
for
that.
Why.
C
And
one
of
the
interesting
things
about
code
too:
is
it
in
some
ways?
Maybe
it's
it's
like.
How
do
you
make
sure
that
that
y
is
captured
as
you
implement
compliance's
code
and
security
as
code,
because
the
how
behind
may
be
different
and-
and
so
you
know,
do
you
do
you
ensure
that
there's
a
comment
that
documents-
the
intent,
really
really
kind
of
interesting
element
to
to
think
through
yeah.
D
D
We
can
talk
about
education,
all
we
want,
but
it's
just
an
unrealistic
numbers
problem
that
we
have
so
shift
left
through
automation
at
least
helps
bridge
that
gap,
because
it's
unrealistic
to
think
that
we
can
educate
the
world
to
be
a
security-centric
mindset.
Not
everyone
is
going
to
be
able
to
be
a
assist
for
a
pen
tester
overnight,
so.
B
So
a
lot
of
the
conversation
I
have
I
talked
about,
you
know,
illegals
and
entities,
and
you
know
that
would
be
things
like
reliability
and
security
would
be
one
of
them
and
the
the
idea
that
you
can
make
all
of
your
developers,
experts
in
distributed
systems
and
building.
You
know
reliability
and
scalability
and
all
these
things
into
into
their
applications.
B
It
is
just
not
possible,
like
it's
at
the
scale
and
the
complexity.
You
want
the
platform
to
be
able
to
keep
all
those
promises,
those
architectural
decisions
that
are
going
to
give
you
the
scalability
reliability,
and
that
this
is
really
the
model
that
you
see
evolved
inside
of
google
with
sre.
To
be
honest,
that
the
the
developers
get
a
focus
more
and
more
on
their
business
logic
on
the
domain.
B
Things
like
scalability
are
solved
because
they're
writing
to
those
libraries
they're
writing
to
those
systems
that
can
keep
those
promises
and
and
security
is
just
another
thing
that
you
want
to
be
baked
into
that
architecture
into
those
platform
services.
So
the
developers
are
not
going
to
be
experts
in
security
and
they
don't
have
to
be.
Thankfully,.
A
A
B
There's
a
lot
to
impact
right,
if
you,
if
you
start
talking
about
the
way
like
I
think
culture
gets
kind
of
thrown
around,
and
we
already
did
it
a
little
bit
on
this
thing
where
it's
like
it's
the
truth,
but
it's
also
sort
of
inactionable
it's
hard
to
like
go
implement
culture
right,
and
so
what
I
try
to
help
people
think
about
is
what
are
the
behaviors
you're
trying
to
get?
And
then
what
are
these
kind
of
practical
activities?
You
could
do
and
and
then
also
be
mindful
about
the
incentives.
B
You
know
the
org
structures
and
incentives
have
been
set
up,
but
there's
really
simple
things
that
in
a
lot
of
organizations
just
as
it
evolved
dynamically
with
whatever
kind
of
silos
in
history,
the
these
roles
don't
even
really
interact
with
each
other
as
human
beings
right.
It's
all.
It's
all
through
ticket
systems,
and
this.
C
And
so
I
think
you
know
an
interesting
thing
to
look
at
is
mean
time
to
resolution
for
newly
discovered
security
issues.
You
know,
and
and
and
potentially
you
could
look
at
what
point
in
the
in
the
life
cycle.
Were
those
issues
discovered
as
well
and
ideally
the
earlier
they're
discovered
the
more
the
easier
it
is
to
address
them.
Now,
that's
never
a
hundred
percent.
D
One
of
the
things
I
see
is
that
the
security
team
is
measured
based
on
the
number
of
things
they
find
and
the
development
team
is
measured
on
the
speed
at
which
they
can
deliver
business
value,
and
these
are
just
totally
conflicting
incentives
and
that's
one
of
the
things
that
really
bothers
me
about
our
organization,
because
security
professionals
at
the
highest
levels
are
taught.
It
is
okay
to
accept
risk.
D
It's
a
simple
math
problem,
despite
the
fact
that
there
might
be
potential
security
impact-
and
I
am
a
cis-
so,
like
me
saying,
accepting
risk
is
fine-
is
almost
counter-intuitive
to
the
standard
security
persona,
but
that's
how
these
setups
are
designed
and
the
incentives
that
we
have
of
find
all
the
bugs
and
deliver
things
fast
are
just
too
conflicting
right
now.
So
if
you
can
change
the
incentives
to
say
if
we
are
able
to
make
more
appropriate
risk
management
decisions,
then
I
think
the
entire
conversation
changes.
A
Nice,
so
let's
talk
about
policy
right,
like
there's
all
kinds
of
policy
out
there
right
we've
got
regulatory
policy,
we've
got
security
policies,
we've
got
you
know,
internal
organizational
policies,
but
usually
the
best
way
to
deliver
a
compliance
system
is
to
continuously
deliver
compliance
right.
So
thinking
about
applying
policies
in
the
way
of
against
infrastructure
to
ensure
safe
deployments
or
ensure
regulatory
requirements
are
met.
A
How
would
you
go
about?
You
know
assessing
what
your
policy
enforcement
should
be
within
your
environment.
In
you
know
any
organization
right
like?
Is
there
a
process
that
you
normally
drive
people
through
or
is
it
more
like?
Well,
it
depends
on.
If
they're
you
know,
financial
services
or
something
else
so.
B
I
think
the
ideal
future
state
you
know
that
we
sort
of
kind
of
hinted
at
earlier
in
this
conversation
is
that
you're
continuously
auditing
and
the
audit
function
is
enforced
by
the
framework
by
the
platform
itself
and
and
then
the
security
professionals
are,
are
making
those
kind
of
creative
investments
and
managing
the
risk
and
thinking
about
what
that
policy
should
be
not
trying
to
audit
it
right.
The
audit
that,
like
computers,
are
really
good
at
doing
repetitive
tasks.
B
C
Right
and
and-
and
I
think
yeah
there
is
there-
there
is
some
really
cool
stuff
going
on,
as
you
say,
transparency
logs
and
like
the
sig
store
project,
and-
and
you
know
how
do
we
think
about
all
of
that
throughout
the
life
cycle?
I
also,
I
also
think
it's
it's.
A
piece
of
the
puzzle
is
at
least
in
the
is:
is
it
what
we
call
in
kubernetes
admission
controls
right?
C
You
can
define
policies
for
kubernetes,
I'm
sure
you
can
do
it
for
other
environments
as
well
in
different
ways
that
check
elements
of
the
solution
that
is
requesting
access
or
requesting
to
be
deployed,
and
in
that
case
kind
of
one
of
the
things
that
comes
up
frequently
is.
Is
that
principle
of
least
privilege
right?
So
so?
Can
I
check
for
the
appropriate
privilege
request
now
that
gets
challenging,
because
you
might
create
a
policy?
That's
that's
fairly.
C
You
know,
after
all,
it's
code
it
it
could
be
fairly
black
and
white
and
then,
if
a
solution
needs
certain
levels
of
privileges
that
you
don't
allow
by
default,
you're
back
to
an
exception
process.
So
you
also
you
know.
There
are
also
interesting
tools.
Emerging
in
that
space
too,
that
help
you
define
fairly
complex
policies.
You
know
opa
and
opa
gatekeeper
in
the
kubernetes
space
and
and
there's
there's
another
policy
engine.
Very
yes,
thank
you.
Kaiverno
in
that
space
as
well
awesome.
A
B
B
These
are
qualities
that
come
from
the
socio-technical
system,
which
is
the
combination
of
those
computing
systems
and
and
those
social
systems
coming
together
to
deliver.
Like
you
can't,
I
mean
just
just
like
you
use
another
analogy
from
reliability.
There's
no
organization
on
this
planet
that
thinks
that
they
don't
need
it
the
sres
right
right.
So
you
can.
B
You
can
invest
in
ai
automation,
you
know
autonomous
systems
whatever,
but
no
one
thinks
right
now
in
2021
that
you
can
just
turn
your
back
on
all
this
stuff
and
it's
going
to
be
good,
and
I
think
that
that
analogy
comes
over
to
security
as
well.
It's
the
social
technical
system
that
delivers
security.
C
Absolutely
I
mean
just
we
think
about
facial
recognition
right.
The
the
facial
recognition
systems
we
have
today
are
partly
driven
by
the
data
that's
fed
into
them,
and
the
and
humans
are
controlling
to
some
extent
what
data
gets
fed
into
them.
That
will
shift
over
time
right,
but
but
but
I
do
think
there
are
some
things
you
know
so
so
yeah,
I'm
with
you.
B
B
D
B
So
so
to
that
point,
if
you
go
look
at
the
the
most
of
the
breaches
that
happen
very
few
of
them,
you
know,
relatively
speaking,
are
because
someone
exploited
some,
you
know
cve
or
whatever.
That's
like
in
in
the
system.
That's
technical,
there's
lots
of
social
engineering
that
leads
to
the
the
breaches.
D
C
B
There's
there's
a
lot
of
people
on
a
lot
of
different
journeys
in
different
places,
and
you
know
we
kind
of
we
kind
of
talked
about
this
in
the
pre-show.
There
there's
been
lots
of
investment,
so
so
here
here's
this
pattern.
I
see
right
now
right
you
go
into
these
organizations
and
they've
got
a
devops
team
which
is-
and
this
is
true-
this
is
a
true
story-
a
devops
team
which
is
a
different
silo
and
a
different
team
than
an
sre
team.
B
That's
a
different
silo
and
different
team
from
the
devsecops
team
and
you're
just
like
what
are
you
doing
right,
like
or
or,
and
maybe
even
sometimes
they'll
have
like
a
cicd
team.
It's
like
you
got
a
devops
team
in
a
cicd
team,
so
I
think
one
of
when
this
goes
back
to
work,
charts
and
funding
models.
C
Yeah-
and
I
ran
into
this
recently
with
an
organization
who
not
only
has
an
infrastructure
security
team,
but
they
have
a
cloud
security
strategy,
team
and
actually
I've
seen
that
emerge
in
more
than
one
organization
right
as
they
start
to
adopt
cloud.
They
create
sort
of
this
special
team.
That's
looking
at
at
cloud
security,
and
so
so
we
get.
We
can
get
even
further
siloed,
as
as
organizations
do
that.
B
C
B
C
C
B
So
so
security
is
an
interesting
one
and
there's
a
number
of
things
that
are
happening.
You
know
in
in
conversation
with
my
team
and
and
we
we
we
are
working
with
product
working
with
there's
some
all
it's
hard.
It's
hard
to
talk
about
some
of
this,
because
people
don't
like
their
logos
or
their
names
like
run
around,
but
you
basically
have
a
lot
of
big
banks.
B
C
B
C
D
So
they'll
work
to
address
these,
but
having
that
conversation
and
allowing
teams
to
prioritize
what
matters
most
is
really
critically
important.
So
what
advanced
cluster
security
is
doing?
Is
it's
doing
your
traditional
vulnerability
management,
but
looking
at
it
from
a
different
angle
by
adding
security
context,
and
it
does
that
through
assumption
of
what
it
knows
to
be
in
kubernetes
and
using
the
kubernetes
api.
So
now
you
can
effectively
say
if
a
container
is
privileged,
what
that
means
is
that
it
has
effectively
root
access
the
underlying
host
operating
system.
C
Although
I
always
want
to
be
careful
to
separate
the
word
privilege
and
root
access,
because
there
are
so
many
different
types
of
privilege
that
that
can
actually
be
supplied,
so
is
it
fair
to
say
that
that
kind
of
what
you're
thinking
of
really
requires
running
as
root
and
access
to
the
to
the
host,
for
example,
just
just
like
think
se,
linux
right
sd
linux-
can
can
provide
some
protections
user
name
space
spaces
help.
I
know
we're
getting
a
little
technical
here
and
then
but
kubernetes
doesn't
yet
support
username
spaces.
D
Yeah,
it's
definitely
about
prioritization
to
me,
because
there's
always
going
to
be
a
defense
in
depth
architecture
and
at
the
end
of
the
day,
you
want
to
build
a
layered
approach
to
security,
where
you
expect
one
or
two
controls
to
fail,
because
ultimately,
a
mature
nation-state
is
going
to
be
able
to
to
attack
you
in
a
more
effective
way
than
someone
who
has
a
limited
budget.
So
the
goal
of
the
security
team
is
not
necessarily
to
secure
all
the
things.
D
The
goal
of
the
security
team
is
to
make
it
too
cost
prohibitive
in
order
for
an
attack
to
be
successful
proportional
to
the
risk
exactly
yeah.
So,
ultimately,
when
I
talk
about
something
like
being
able
to
prioritize
more
effectively
saying,
a
privileged
container
is
root
on
the
operating
system,
but
that
is
what
it
means
to
be
privileged
in
the
context
of
kubernetes.
D
Now
that
being
said,
if
I
have
a
privileged
container,
I
wanna
and
I
wanna
be
able
to
block
anything
to
with
the
network
attack
vector
or
an
adjacent
network
attack
vector.
That
is
a
a
critical
vulnerability
or
a
high,
and
I
wanna
do
that
instantly
and
maybe
for
a
privileged
container.
I
might
even
want
to
go
down
to
the
medium
level
for
that
so
being
able
to
make
more
informed
risk
management
decisions
on
what
matters
most
is
really
key.
So
what
we
see
is
organizations
will
use
labeling
strategies
with
their
their
crown
jewel
applications.
D
So
if
an
application
doesn't
have
sensitive
data,
then
if
it
and
isn't
does
it
isn't
even
exposed
to
an
external
network?
Maybe
it's
acceptable
to
have
a
high
risk
for
that
organization,
whereas
if
it's
a
crown
jewel
application,
that's
externally
exposed
and
privileged.
Maybe
you
want
to
start
tackling
the
mediums
right.
C
Absolutely
I
think,
that's
that's!
Why
that's
another
place
where
again,
we
kind
of
we
need
to
blend
socio-technical
right,
so
there
there's
some
human
perspective
here,
but
also
the
computer
and
and
a
solution
like
acs
right.
The
software
can
gather
additional
data
to
inform
the
decision
in
ways
that,
if
you
are
just
looking
at
vulnerabilities
through
an
sca
analysis
right,
a
software
composition.
Analysis
where
they've
said
here
are
the
packages
in
the
software
here
are
the
known
vulnerabilities
associated
with
that
software.
C
B
So
I
I
like
to
drag
everything
back
to
you
know
the
center
of
what
I
I
understand,
which
is
you
know,
devops
sre
type
stuff
and
I
think,
there's
an
interesting
conversation
emerging
and
I've
been
part
of
having
some
of
it
around
framing
some
of
these
conversations
through
through
the
same
lens
right.
So
when
you
talk
about
risk
and
reliability,
the
they're
not
exactly
the
same,
and
I
think
it's
it's
easier
to
measure
reliability
than
it
is
to
measure
risk.
To
be
honest.
B
B
C
Yeah
absolutely
right
about
observability.
I
I'm
going
to
ask
a
question
that
I
get
asked
which
is
interested
in
the
perspective
from
the
two
of
you.
You
know
how
does
devsecops
shift
left
help
us
address
ransomware
or
does
it
and-
and
you
know
what
what
do
you
think
you
know
what
what
are
some
of
the
best
practices
when
we
think
about
ransomware.
A
D
C
D
C
B
Yeah,
I
I'll
add
to
what
jamie
said
and
it's
similar
to
like.
There's
no
there's
no
organization,
that's
not
going
to
have
outages
right,
like
you're,
going
to
have
some
corner
case
some
new
thing
that
changes
some
of
the
assumptions,
but
what
you
can
do
with
with
these
investments
is
you
can
have
a
better
understanding
of
what
software
is
running?
C
No
and
and
here's
the
one
place
that
I
so
so
there
are
two
things
I
I
like
to
use
as
an
answer.
One
is,
you
know,
provide
as
much
protection
as
you
can.
The
way
you
would
normally
do
the
observability
is
is
critical
right
because
you
need
to
also
detect
and
respond,
but
I
think
also
we,
you
know
more
and
more
the
more.
B
B
Things
constantly
so
recovering
is
you
know
the
same
as
all
your
other
deploys
at
the
same
time
like
that,
doesn't
necessarily
protect
you,
because
you
don't
know
where
some
of
those
vulnerabilities
came
into
your
supply
chain,
so
you
might
just
be
redeploying
them
anyway,
and-
and
I
understand
what
j
james
said
ago
and
use
an
analogy
from
from
like
physical
security
at
my
house.
So
so
I
have.
I
have
a
security
system
and
there's
like
sensors
and
like
all
this
stuff.
C
D
C
A
Apologies
for
the
technical
difficulties,
folks,
my
comcast
issues
are
being
buried
right
now,
meaning
the
cable
is
being
buried.
Hence
the
network
loss
of
connection
so
and
the
cell
networks
are
not
as
strong
as
they
were
after
the
storms.
We
had
so
joining
from
my
ipad
as
it
were.
So.
Thank
you
all
for
joining
today
and
discussing.
C
I'll
grab
it
first,
I'm
really
excited
by
what's
happening
with
signing
transparency
logs
the
whole
sig
store
initiative
and
investments
around
attestation.
I
think
there's
some
really
cool
stuff
happening
that
will
allow
us
to
to
make
zero
trust
more
than
than
just
or
extend
some
of
what
is
zero
trust
today
in
red
hat
solutions,
but
but
extend
it
to
more
parts
of
of
the
of
the
process
and
the
software.
A
B
B
The
stuff
with
you
know
the
audit
logs
the
transparency
logs.
That's
great,
the
other
thing
that
I'm
faced
with
you
know
and
and
I'll
say
this
is
true
about
devops,
the
the
the
forward-leaning
conversations
and
kind
of
like
the
pushing
the
boundaries
of
this
is
one
thing,
but
the
vast
majority
of
organizations
in
some
ways
like
they're,
just
getting
caught
up
to
devops
conversations
from
2010
right.
So
so
to
me,
like
the
most
exciting
thing,
is
about
bringing
the
standard
up
across
the
the
industry.
B
D
All
right
jamie,
I
I
was
someone
who
came
over
with
the
stack
rocks
acquisition.
So
to
me
one
of
the
things
that
really
excites
me
is
to
be
able
to
attempt
to
disrupt
the
kubernetes
security
space
at
scale
and
by
transitioning
from
a
startup
to
a
large
enterprise,
with
a
huge
presence
in
the
enterprise
space.