►
Description
The modern automated software development and deployment process automates a lot of build, test, and deployment steps. Where and how should we embed security controls so that they adequately mitigate risks without affecting the velocity of software delivery or introducing toil? In this webinar we first survey the typical deployment pipeline and the threats that we should mitigate, and then propose a reference architecture for embedding security controls. We will conclude with some practical examples of security tools that can be embedded across the software delivery lifecycle.
Presenter:
Vinay Venkataraghavan, Cloud CTO, Prisma Cloud @Palo Alto Networks
A
So
hi
everyone
good
morning,
good
afternoon,
good
evening,
depending
on
where
you
are
in
the
world.
Welcome
to
today's
cncf
webinar,
modern
software
development
pipeline,
a
security
reference
architecture,
I'm
christy
tan
I'll,
be
monitoring
today's
moderating
today's
webinar.
We
would
like
to
welcome
our
presenter
today,
vinay
vince
carstegen
cloud
cto
at
prismacloud
at
palo
alto
networks,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
in
your
questions
and
we'll
get
to
as
many
as
we
can.
In
the
end,
this
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenter.
A
B
B
A
B
So
this
is
the
scale
that
the
cloud
is
affording.
However,
the
biggest
benefit
of
these
two
advancements
is
the
ability
to
deploy
software.
Much
faster
gone
are
those
days
when
software
is
deployed
at
a
six-month
development
cycle
and
companies
are
bringing
to
market
new
technologies
twice
a
year,
albeit,
dare
I
say
there
are
many
customers
who
are
deploying
software
and
bringing
new
capabilities
to
market
on
a
weekly
basis,
and
there
I
say
multiple
times
a
day.
B
B
That
sounds
great.
However,
all
of
this
cloud-
innovation,
as
I
mentioned,
comes
with
many
security
challenges:
a
palo
alto
network's
unit,
42
research
team
that
analyzed
more
than
200
000,
publicly
available
infrastructure
as
code
templates
from
some
very,
very
scary
pieces
of
information
there
I
say
which
really
renders
a
lot
of
this
infrastructure
exploitable
to
breaches
so,
for
example,
cloud
formation
templates,
terraform
templates
and
other
types
of
templates
form
the
bedrock
for
the
deployment
of
large-scale
infrastructure
on
cloud
and
container
environments,
and
we
found
that
42
of
cloud
formation
templates
are
insecure.
B
So
what
that
means
is
when
these
templates
are
actually
leveraged
and
deploying
these
applications
in
production.
They
are
such
that
they
have
mis
configurations
that
are
susceptible
to
breaches
and
exploits.
Similarly,
the
cloud
native
model
has
also
seen
a
great
increase
in
the
adoption
of
open
source
software
and
technologies.
B
B
So
it's
very
very
important
to
make
sure
that
these
vulnerabilities
are
patched
and
addressed
in
a
timely
manner
and,
more
importantly,
at
the
right
junctures
before
being
deployed.
And
finally,
compliance
is
a
big
task
in
the
cloud
as
well.
There
are
mission,
critical
applications
that
are
being
deployed
in
cloud
and
container
native
environments,
but
the
hard
part
is
that
there
is
no
single
source
of
truth,
which
says
that
here
are
the
37
compliance
controls
that
enterprises
need
to
enforce
to
ensure
that
the
gdpr
compliant
or
hipaa
compliant,
for
example.
B
So,
let's
now
talk
about
the
modern
software
deployment
pipeline.
So
typically,
this
console
consists
of
the
build,
deploy
and
run
phases
and
what
I've
tried
to
characterize
in
this
diagram
here
by
the
rectangular,
rounded
rectangular
circles,
is
the
how
these
threats
actually
manifest
themselves
in
throughout
your
deployment
pipeline,
so
rather
than
starting
at
the
in
the
right,
which
is
your
runtime
environment.
B
Let's
shift
left
and
let's
talk
about
how
these
security
threat
vectors
precipitate
across
the
software
development
pipeline,
as
we
talked
about
it,
its
infrastructure
as
code
is
tremendously
leveraged
to
deploy,
along
with
automation,
repeatable
and
reproducible
infrastructures,
and
we've
talked
about
the
fact
that
you
know
devops
engineers
cannot
be
expected
to
be
security
experts.
So
therefore
there
are
a
lot
of
misconfigurations
that
percolate
through
your
build
deploy,
phases
and
precipitate
in
in
misconfigured
infrastructures.
B
In
your
run
time,
so
we
need
to
make
sure
that
we
we
have
full
visibility
into
the
misconfigurations
in
your
infrastructure
score.
Similarly,
the
docker
files,
which
are
the
building
blocks
for
your
containerized
applications,
also
contain
numerous
entry
points.
If
you
will
so
to
speak,
where
security
misconfigurations
can
result
in
drastic
implications.
In
the
runtime
and
finally,
a
number
I'm
putting
on
my
developer
hat,
you
know
when
developers
find
reusable
software.
I
mean
that's
what
it's
all
about.
B
You
don't
want
to
reinvent
the
wheel,
so
we
we
leverage
a
new
package
that
is
out
there
in
different
software
repos.
However,
we
have
no
visibility
into
the
vulnerabilities
that
are
contained
in
these
reports,
so
these
are
all
the
areas
where
these
new
threat
vectors
get
injected
into
our
software
applications
that
move,
for
example,
from
the
build
phase
into
the
deploy
phase.
B
So
in
the
deploy
phase,
now
that
your
artifacts
have
been
deployed,
artifacts
have
been
built,
for
example,
your
container
images
and
now
you're
using
these
infrastructure
as
code
and
also
representing
all
aspects
of
your
applications.
As
of
your
continuous
applications,
for
example,
as
kubernetes
manifest
and
now
you're
ready
to
deploy
them.
However,
you
have
typically
devops
engineers
are
moving
at
a
very
rapid
pace
and
don't
pay
particular
attention
into
the
configurations
in
their
kubernetes
manifest
that
could
actually
result
in
exploits
that
are
happening
in
the
runtime.
B
So,
just
to
give
you
a
quick
example,
a
simple
example
is
the
security
context.
For
example,
to
make
sure
that
a
container
unless
absolutely
necessary
doesn't
run
in
a
privileged
context,
so
we
all
know
that
the
threat
vector
there
is
for
malware
and
code
that
exploits
privilege.
Escalation
can
actually
do
a
container
escape
access.
The
host
exploit
the
host
and
could
add,
could
exploit
it
in
terms
of
denial
of
service
attacks,
data,
exfiltration,
etc.
A
B
We
keep
continuing
to
build
the
story
now.
These
are
the
artifacts
that
are
going
to
deploy
your
applications
in
your
runtime,
so
you
have
a
large
number
of
continuous
applications
running
as
microservices
on
your
kubernetes
platform
that
that
have
many
potential
misconfigurations,
which
can
be
exploited
by
your
bad
actors,
etc.
So
it's
very
very
important
to
have
full
visibility
into
these
threat
vectors
and
also
understand
in
the
context
of
the
modern
software
pipeline.
What
these
threat
factors
are
and
to
make
sure
that
we
can
take
the
appropriate
remedial
action.
B
So
what
is
really
needed
is
an
integrated
and
a
comprehensive
approach
is
required.
So
what
does
that
mean?
That
means
that
you
know
you
need
to
have
protection
across
the
entire
development
life
cycle
throughout
the
build,
deploy
and
run
phases.
So
security
needs
to
be
integrated
and
automated
and
should
not
be
an
afterthought.
B
Secondly,
we
all
are
very
familiar
with
the
the
friction,
if
I
may
say,
between
devops
and
security
security
teams
think
that
they
don't
trust
devops
to
get
security
right.
However,
devops
teams
feel,
like
security,
doesn't
understand
their
need
for
agility
and
feel
that
security
is
always
bolted
on
and
actually
inhibits
the
need
for
their
agility
and
bring
all
these
innovative
applications
to
market.
B
So
what
is
really
really
required
is
for
security
teams
and
devops
teams
to
meet
in
the
middle
and,
more
importantly,
for
security
teams
to
empower
devops
teams
with
the
right
tools
and
the
capabilities
to
natively
inject
security
throughout
the
build
and
deploy
phases.
Because,
as
we
talked
about
it,
there
is
another
dimension.
That's
very,
very
important.
Security
cannot
be
bolted
on
because
cloud
native
applications,
it's
not
they're,
not
static,
they're,
highly
dynamic
environments
that
are
that
are
built
torn
down.
B
They
are
they
massively
scale,
so
security
needs
to
be
deployed
in
a
manner
that
scales
to
meet
the
devops
and
the
cloud
native
continuum.
So
security
teams
need
to
bring
the
right
tools
and
the
capabilities
to
enable
those
positive
and
desirable
security
outcomes,
and
finally,
I've
also
also
talked
about
that
fact.
I
mean
change
is
the
only
constant
you
know.
It's
not
only
containers,
but
an
application
stack
in
the
cloud
container
is
composed
of
virtual
machines,
containers
and
serverless
capabilities.
B
Therefore,
you
need
a
uniform
capability
to
bring
in
cohesive
security
for
each
of
these
applications
assets
and
paradigms.
You
can't
have
a
one
kind
of
a
security
capability
for
your
virtual
machines,
yet
another
kind
of
security
capability
for
your
containers
and
yet
another
type
of
security
capability
for
your
serverless
capabilities.
So
you
need
a
cohesive,
uniform
pattern
for
security
that
you
can
apply
across
the
entire
application
stack
with
that
I'd
like
to
introduce
the
security
reference
architecture
for
cloud
native
applications
and
ci
cd
pipelines.
B
This
architecture
is
very,
very
important
for
two
reasons:
it
gives
devops
practitioners,
it
gives
security
architects.
It
gives
c
c
I
o
c
to
ctos
and
c
source,
a
bird's
eye
view
into
all
the
different
components
that
comprise
a
comprehensive
stack
to
deploy
cloud
native
applications,
cloud
native
and
container
applications
in
various
different
types
of
cloud
platform,
cloud
and
container
platforms.
B
B
Throughout
each
phase,
the
phases
are
logically
broken
up
into
the
development
phase,
where
it's
the
developer,
that's
developed,
developer
and
the
devops
team
that
are
building
the
the
applications
and
the
infrastructure
as
code
templates,
and
then
we
also
provide
the
hooks
necessary
from
as
pre-commit
hooks,
for
example,
and
we
get
into
the
details
on
the
operational
view
and
as
I
call
this,
this
is
the
technology
view,
but
there
is
the
opportunity
to
inject
security
in
the
in
the
development
phase.
Similarly,
there
is
yet.
A
B
So
I
like
to
call
this
the
technology
view,
as
we
call
out
all
the
all
the
points
of
injection
of
the
native
capabilities
for
a
ci
cd
pipeline
as
well
as
security
from
the
in.
If
you
look
at
the
right
through
from
your
code,
commit
through
your
cicd
pipeline,
as
well
as
in
the
runtime
in
terms
of
your
ias,
pass
and
container
as
a
service
capabilities
coupled
with
a
uniform
policy
layer
that
ensures
that
the
appropriate
policies
are
applied
across
the
entire
cloud
development
and
deployment
continuum.
B
So,
let's
now
take
a
pivot
to
take
an
operational
view
to
recognize
what
this
would
actually
look
in
a
real
operational
environment.
So,
as
you
can
see
from
a
horizontal
perspective,
this
is
logically
divided
into
the
build
phase.
The
the
development
phase
at
the
top,
the
the
middle
layer,
if
you
will
is
the
dipper,
is
the
build
phase
and
in
the
final
in
the
layer
you
have
the
deployment
assess
the
runtime.
So
let's
address
each
of
these
internal.
B
You
know,
as
I
talked
about
it,
in
a
traditional
model
where
developers
deployed
code
security
teams
did
the
scan
at
a
much
later
point
and
came
back
with
the
results
to
make
changes.
I
mean
the
developer
and
the
devops
architects
have
actually
moved
on
to
their
next
features
that
they
need
to
develop
and
bring
to
market.
So
it's
unreasonable
to
access
expect
them
to
actually
go
back.
So
this
instantaneous
feedback
loop
is
highly
critical
in
order
to
make
sure
that
you
have
the
the
right
security
posture.
So
let's
talk
about
each
one
of
that.
B
In
the
first
phase
we
talk
about
the
developer
ide.
This
is
where
the
develop
the
devops
teams
are
building
their
infrastructure
as
code
that
they're
defining
they're
writing
their
kubernetes
app
application,
manifest
they're,
developing
the
applications
and
if
you
can
get
the
feedback
from
a
security
perspective
to
the
developer
right
in
the
ide,
it's
incredibly
powerful.
B
So,
let's
take
a
look
at
that
right,
so
any
in
insecure
configurations
that
are
detected
in
your
docker
files
in
your
kubernetes,
manifest
as
well
as
infrastructure
escort,
can
be
scanned
as
a
pre-pre-hook
commit,
or
even
in
your
ide,
across
your
development
and
in
development
environment
policy.
So
I
call
it.
You
have
three
distinct
policy
sections.
One
is
your
development
environment
policy,
where
it's
a
loser
set
of
policies,
because
you
need
your
developers
to
be
able
to
develop
applications
test
it
and
play
around.
B
So
it's
a
broader
set
of
guard
rails,
but
across
those
three,
those
four
dimensions
of
making
sure
that
you're
incorporating
static
analysis,
vulnerability
scanning
infrastructure
as
code
scanning,
as
well
as
a
kubernetes
application,
manifest
scanning.
So
it
is
the
all
the
scans
happen
according
to
your
dev
environment
policies,
and
if
there
are
any
failures,
there
is
an
instantaneous
feedback
loop
to
the
developers
and
the
devops
teams
to
actually
make
the
necessary
corrections.
B
So
once
all
the
the
necessary
dev
environment
policies
have
passed,
the
code
actually
gets
checked
into
your
source
code
management
system
in
step,
number
five
and
then
what
happens
next
is
to
actually
go
into
your
build
phase
where
you're
now
actually
going
through
the
phase
of
building
all
the
different
types
of
artifacts.
In
this,
for
the
purposes
of
our
conversation
here,
I'm
going
to
talk
about
the
containers,
but
you
can
see
how
you
can
have
a
uniform
posture
across
building
your
cloud.
B
Amis,
if
you
will
your
virtual
machine
images,
the
container
images,
as
well
as
the
server
images,
so
your
build
process
is
actually
going
to
execute
the
docker
files.
If
you
will
to
actually
bring
all
the
necessary
packages,
build
the
container
image
and
then
actually
results
in
the
in
the
in
a
container
image,
that's
checked
into
a
container
registry.
B
The
next
phase
is
you
also
want
to
make
sure
that
you're
securing
the
software
supply
chain,
so
you
can
also
have
a
policy
which
says
that
no
image
that
has
not
been
appropriately
signed
according
to
your
enterprise
standards
can
ever
be
deployed
in
your
environment.
So
you
make
sure
that
just
images
are
signed.
The
next
phase
is
your
application
testing.
So
you
go
through
your
unit
system
and
integration
tests
once
again,
which
is
which
is
a
model
that
we
are
all
very
very
familiar
with,
is
if
there
are
any
failures
that
get
the
feedback.
B
Loop
goes
back
to
the
developer
and
they
go
and
iterate.
But
if
everything
passes
now
you
can
go
to
the
next
phase.
Where
now
we
are
incorporating
infrastructure
as
code
scanning
for
your
kubernetes
application,
manifest
your
terraform
as
well
as
your
cloud
formation
templates
and
as
you
can
see,
we
talked
about
it
just
to
once
again
bring
a
little
bit
more
of
that
context.
To
showcase
how
you
can
surface
a
lot
of
those
insecure
configurations
in
your
build
and
the
deploy
phases
prior
to
deploying
these
artifacts
in
the
runtime?
B
Similarly,
you
can
scan
all
your
container
images
according
to
your
enterprise
policies,
now
you're
executing
it
on
your
test,
environment
policies,
which
is
probably
a
much
more
stricter
and
narrower
set
of
policies
against
which
you
perform
all
of
these
scans.
If
there
are
any
failures
once
again
it
the
feedback.
Loop
goes
back
to
the
devops
teams
to
make
the
necessary
configured
corrections.
If
all
of
that
passes,
we
now
go
into
the
deploy
phase,
where
you
perform
the
validation
of
the
the
the
the
images
hashes
and
the
and
the
signatures
it.
B
You
apply
the
runtime
policies,
and
then
it
goes
into
the
runtime
and
from
a
runtime
perspective,
I
want
to
talk
about
three
four
different
pillars.
You
need
to
make
sure
that
your
container
orchestration
platform
is
appropriately
configured.
I
mean
kubernetes,
for
example,
is
an
incredibly
powerful
and
a
complex
system,
but
you
need
to
make
sure
that
it's
appropriately
configured
to
give
you
an
example.
The
kubernetes
api
server
should
never
be
exposed
to
the
outside
world.
It's
very
easy
to
see
how
you
can
actually
have
a
denial
of
service.
B
I
just
want
to
talk
about
one
particular
control
that
it
calls
out,
for
example,
where
you
want
to
make
sure
that
your
container
applications
are
limited
in
the
in
the
way
in
which
they
can
abuse
resources
and
execute
privilege
escalation
or
execute
unsanctioned
binaries,
for
example.
So
all
of
these
different
controls
can
be
executed
in
your
runtime,
and
then
you
can
also
apply
all
of
these
capabilities
for
your
hosts
and
apply
compliance
controls
for
your
host.
B
Make
sure
that
you
have
fine-grained
micro
segmentation
as
well
as
last,
but
not
least,
make
sure
that
you
have
the
right
container
and
pod
security
policies,
you're,
making
sure
that
the
only
sanction
processes,
files
and
from
a
network
perspective
you
have
limiting
only
sanctioned
access
so
from
an
up.
This
is
a
operational
view
on
how
to
actually
take
all
of
these
capabilities
of
the
technology
overview
of
the
security
reference
architecture
and
bring
it
into
from
an
operational
as
an
operational
perspective.
B
And,
finally,
before
we
go
into
probably
the
most
interesting
part,
which
is
the
demos
I
also
want
to
talk
about.
You
know
cloud
native.
What
a
a
very
very
important
characteristic
is
scale,
so
any
manual
processes
is
a
recipe
for
disaster,
so
you
want
to
make
sure
that
you
are
automating
all
aspects
of
the
modern
security
pipeline.
So
what
that
means
is
representing
your
security
policies.
B
So
if
we
have
applied
all
of
these
concepts
and
principles
in
terms
of
automation
and
applying
the
cloud
operating
model
in
conjunction
with
making
sure
that
security
is
deployed
throughout
the
build,
deploy
and
run
phases
with
continuous
integration,
continuous
deployment
security
is
treated
as
a
first
class
citizen
and
it's
not
an
afterthought.
So
a
tremendous
benefit
here
is
now
the
attack
surface
is
dramatically
reduced
by
the
application
of
the
appropriate
security
controls.
B
So
the
last
point
that
I
want
to
make
here
is,
as
you
can
see,
security
now
scales,
along
with
the
applications
to
meet
the
needs
of
both
the
cloud
native
applications,
as
well
as
the
requirements
of
the
devops
teams.
So,
let's
put
all
of
this
in
context
now,
as
I
mentioned
earlier,
it's
very
important
to
make
sure
that
you
have
the
capabilities
such
as
performing
the
infrastructure
as
code
scanning
right
at
the
developer
ides.
It
can
also
be
done
as
a
step
in
your
ci
cd
pipeline,
which
we'll
see
very
very
shortly.
B
B
This
is
what
they
do
all
the
time,
but
if
you
can
provide
the
security
feedback
to
them
in
terms
of
non-compliance
and
failures
from
a
security
perspective,
the
devops
person
can
actually
make
the
necessary
changes
and
go
through
their
development
process.
They
can,
if
there's
a
failure,
they
can
make
sure
that
they
fix
it
and
it
goes
throughout
the
pipeline
once
it
executes
all
the
necessary
steps
from
an
infrastructure
as
code
as
well
as
an
application
manifest
scanning.
If
all
of
those
passed,
then
it
actually
goes
into
your
source
code
management
system.
B
The
next
step
is
now.
You
can
potentially
scan
your
container
images
in
your
registry.
You
have
a
full
manifest
of
all
the
different
packages.
You
have
all
the
vulnerabilities
that
exist
if
there
are
fixes
that
are
available.
So
now
you
can
apply
your
enterprise
right
policies
to
make
sure
that,
for
example,
all
critical
vulnerabilities
are
fixed.
B
If
they're
not
they
go
back
to
the
to
the
devops
teams
to
make
the
necessary
changes
and
if
everything
passes,
then
you
actually
deploy
to
the
cloud
or
the
container
environment
and
it's
very
important
to
realize
that
this
concept
of
devops,
as
well
as
devsecops.
It's
a
continuous
process
where
you
identify,
respond,
detect
and
adapt.
B
I
just
also
wanted
to
showcase
once
again.
This
is
a
real
world
example
of
a
financial
enterprise
deploying
using
these
capabilities
to
deploy
a
very,
very
complex
application
in
a
cloud
environment
across
both
virtual
machines
and
cloud
etc.
Where
now
you
can?
Actually,
if
we
didn't
have
these
capabilities
of
infrastructure
as
code
scanning,
it's
it's
possible
that
you
deploy
very,
very
insecure
configurations.
For
example,
you
deploy
a
database,
that's
that's
can
be
accessed
from
the
internet
or
the
database
is
not
encrypted,
etc.
B
All
of
these
misconfigurations
can
be
caught
in
your
build
and
deploy
phase.
It
goes
through
a
security
scan,
for
example,
through
your
choice
of
ci
cd
platform
and
tool.
You
identify
and
fix
these
security
issues.
This
really
this
whole
process
really
enables
much
better
security
outcomes
that
scales
to
meet
the
demands
of
applications
and
cloud
native
deployments
and,
finally,
once
again,
where
this
this
whole
concept,
where
we
have
the
application
team,
the
devops
team
and
the
security
teams
working
in
concert
where
applications
push
new
application.
B
Devops
teams
push
new
applications
into
the
runtime
environments,
and
security
teams
can
now
reason
about
their
policies
and
all
aspects
of
their
configurations
as
code
and
can
now
actually
check
in
code.
They
can
reason
about
it
goes
through
their
deployment
and
a
code
approval
process,
but
then
it's
highly
automated,
so
they
can
now
no
longer
be
road
barrier
roadblocks
to
devops
teams,
but
can
now
meet
the
same
types
of
agility
of
the
security
teams.
B
With
that
I'd
like
to
now
pivot
to
providing
the
demonstrating
how
you
can
actually
leverage
all
of
these
capabilities
and
make
it
actionable
to
address
real
world
use
cases.
So
the
first
use
case
that
I
want
to
talk
about
is
the
identifying
and
scanning
your
kubernetes
manifests
within
your
developer
ide.
So
I
have
a
container
here.
I
have
a
for
example.
I
have
a
simple
container
definition
here
and,
as
as
some
of
you
might
notice,
there
are
some
glaring
issues
but
problems.
So,
let's
figure
out
what
these
problems
are.
B
And,
as
you
can
see,
this,
the
scan
gives
me
instantaneous
feedback
right
within
the
ide,
which
tells
me
that
this
container
is
running
it's
a
privileged
container,
so
immediately.
The
devops
engineer
should
make
sure
that
they
need
to
go
back
and
revisit
to
say:
hey.
Does
this
container
really
need
to
be
a
privileged
container
because
we
all
know
the
exploits
that
can
be
executed
as
a
consequence
of
it?
B
Secondly,
we
all
know
even
from
the
nist
800-190,
where
you
should
never
run
your
containers
as
the
root
user,
so
entry
point
of
the
container
must
be
run
with
the
user
with
a
higher
user
id.
So
we
know
that
we
shouldn't
be
so.
But
the
point
here
is
that
you
can
actually
make
all
of
these
modifications
right
in
the
ide
prior
to
the
deployment
of
this
application.
So
now
I
want
to
quickly
pivot
to
actually
showcasing
how
we
can
perform
a
similar
scanning
for
infrastructure
as
code.
B
Okay,
so
now
here
what
I
have
is,
I
have
my
infrastructure
as
code,
and
it
also
forms
the
bedrock
for
a
lot
of
these
capabilities,
and
now
I
want
to
execute
the
prismacloud
scan
on
my
infrastructure
as
code
templates,
so
once
the
scan
executes.
So
what
this
tells
me
is
once
again.
The
theme
here
is,
you
know:
devops
engineers
cannot
be
security.
Experts
and
security
experts
have
those
deep
expertise
and
domain
knowledge,
but
what
this
tells
me
is
my
s3
buckets
are
accessible
to
the
public.
My
s3
object,
versioning
is
assembled.
B
B
So,
as
you
can
see,
I've
now
ensured
that
versioning
is
enabled
for
my
buckets.
I've
made
sure
that
it's
not
world
readable.
These
are
these
buckets
are
private,
so
you
can
see
how
we
can
provide
this
instantaneous
feedback
to
the
developers
and
the
devops
teams
to
make
the
necessary
changes
to
truly
afford
a
more
robust
security
posture.
Now.
The
next
two
demos
that
I
want
to
showcase
is
the
integration
with
the
ci
cd
pipeline.
So
what
I
have
here
is
I
have
a
a
docker
file.
B
Let's
look
at
my
docker
file.
It
builds
a
security
adapter
that
I
have
implemented,
but
what
I
want
to
do
is
make
a
few
changes
to
trigger
a
build
in
a
pipeline
to
showcase
how
it
automatically
can
detect
and
provide
the
the
security
feedback
to
your
devops
and
devops
teams
right
within
the
the
github
workflow.
So
let's
make
a
small
change
here.
Let's
add
a
new
license:
let's
save
this
change.
B
So,
as
you
can
see,
we
have
now
executed
a
scan
on
this
image
and
we
have
the
results
right
in
the
console
and
you
get
workflow.
So
developers
have
full
context
so
now
they
know
what
the
problems
are.
So,
for
example,
this
is
the
particular
cve.
It
has
a
critical.
It
has
a
severity
of
critical
and
it
also
tells
you
which
version
what
is
the
fixed
status
when
was
it
published?
So
there
is
very,
very
contextual
and
powerful
information
that
is
provided
to
devops
engineers
and
it
also
executes
a
whole
bunch
of
compliance
checks.
B
So,
for
example,
this
is
now
we're
actually
executing
it.
When
you
perform
a
pull
request,
if
you,
if
you,
if
you
think
about
it,
and
then
it
tells
me
that
this
image
should
be
created
with
an
on
road
user,
so
you
can
see
how,
based
upon
all
the
different
compliance
policies,
you
can
provide
very,
very
powerful
feedback
to
the
devops
engineers
to
be
able
to
make
the
necessary
modifications
and
the
remediations
and
then
go
through.
B
So
you
can
ensure
that
the
images
that
are
deployed
are
highly
compliant
and
appropriately
secured
when
they
are
run
in
the
runtime.
So
the
final
demo
that
I
would
like
to
demonstrate
now
is
the
scanning
of
infrastructure,
as
code
templates
within
the
from
within
a
ci
step
or
for
your
of
your
platform
of
choice.
So
I'm
going
to
now
make
a
change
here
just
to
trigger
a
scan
of
this
code.
So
let's
look
at
it.
B
B
B
So
it's
going
to
go
through
the
different
steps
for
this
particular
environment.
It's
going
to
clone
the
repository
it's
preparing
for
scanning
and
very
very
shortly
in
a
in
a
matter
of
a
few
seconds.
We
will
have
the
the
results
of
that
scan.
So
if
the
scanned
results
don't
match
your
compliance
and
enterprise
security
policies,
the
build
will
fail
and
you'll
have
very,
very
contextual
information
and
I'm
going
to
showcase
how
we
can
actually
use
the
information
that
is
as
a
consequence
of
the
security
failure
to
actually
make
fixes.
B
So
what
this
says
is
the
prismacloud
iac
scan
failed
with
security
issues
based
on
the
configuration
of
the
policies
where
there
is
one
high
severity
violation
and
there
is
a
medium
severe,
a
medium
severity
violation
which
meets
or
exceeds
the
failure
criteria.
So,
based
on
this
feedback
here
I
know
what
the
the
problem
is
and
in
the
interest
of
time
I
just
want
to
show
you
how
we
can
address
it.
B
B
B
B
And
in
a
matter
of
a
few
seconds,
you
can
have
instantaneous
feedback,
so
I
really
want
to
reiterate
the
concepts
of
meeting
security.
This
is
the
concept
of
security
meeting
devops
and
really
really
transforming
it.
Transforming
the
build
pipeline
into
a
modern,
ci
cd
pipeline
where
security
is
injected
right
throughout
the
build,
deploy
and
the
run
phases,
and
this
kind
of
a
posture
really
really
helps
security
scale
and
tremendously
limits
the
attack
and
threat
vectors.
B
So
once
again,
I
I
know
that
I
have
a
policy
which
says
that
I
need
to
have
it's
a
very,
very
restrictive
policy,
as
you
can
see
here,
but
I
have
a
policy
which
says
that
I
should
not
have
any
high
severity
or
any
any
any
any
security
issues
at
all.
But
if
you
notice
we
had
the
high
severity
security
issue,
we
fixed
it
now.
B
So,
let's
now
pivot
back
to
our
presentation,
so
that
I
can
you
know
summarize
all
these
different
capabilities
of
our
platform.
But
the
most
important
point
here
is
it's
it's
a
modern
software
pipeline
and
for
cloud
and
container
native
applications.
We
need
to
make
sure
that
security
is
a
first-class
citizen
and
deployed
at
the
right
interjection
points
throughout
the
build
deploy
phases
because,
as
we
know
very,
very
well-
security
cannot
be
bolted
on
and
it
doesn't
scale
to
meet
the
needs
of
a
highly
dynamic
environment.
B
We
have
some
resources
that
we
provide
to
really
help
our
the
community,
as
well
as
our
customers
along
this
journey
and
we've.
You
know
in
terms
of
our
cloud
native
security
report,
as
well
as
a
blog,
where
we
really
are
very,
very
conscious
of
what
that
posture
needs
to
be
where
security
teams
need
to
really
really
empower
devops,
I
mean
that's
the
secret
to
success
for
cloud
native
security
and
a
modern
cicd
pipeline
with
that.
Thank
you
very
much
and
christy.
Maybe
we
can
open
it
up
to
some
questions.
A
Yes,
I
think
we
might
excuse
me,
I
think
we
might
have
had
a
question
in
the
chat
I
just
I
think
it
might
have
disappeared.
So
if
you
have
a
question
for
vinay,
please
drop
your
questions
in
the
q,
a
box
we'll
just
give
folks
a
another
quick
second
here
and
see
if
anything,
populates
thanks
again
for
the
presentation.
B
A
Yeah
I
wasn't
able
to
oh,
I
think
we
have
it.
It
looks
like
this
is
kind
of
product
specific,
so
we'll
go
ahead
and
have
you
answer
that
one
off
the
line
just
because
we
want
to
keep
this
more
general
and
open
source
focused?
Is
it
it's
a
cncf
webinar,
but
I'll
go
ahead
and
forward
it
to
you
and
we'll
get
your
question
answered
don?
Are
there
any
other
questions
for
vinay.
A
Just
give
folks
another
minute
shy
group
this
morning
or
afternoon
I
guess
vinay
is
there.
I
think
you
had
it
on
your
slide,
but
if
people
are
want
to
contact
you
offline
or
find
out
more
information,
I
think
you
might
have
had
a
slide
on
that.
Do
you
want
to
pull
that
up?
Just
like
I
can
find
out
more
information.
B
A
A
All
right
great
well,
thank
you
again,
vinay
for
a
great
presentation.
Thank
you
all
for
attending
a
friendly
reminder
that
the
webinar
slides
in
the
recording
will
be
posted
later
today
to
the
cncf
webinars
page.
I
hope
everyone
has
a
great
rest
of
the
week
and
we
hope
to
see
you
at
a
future
cncf
webinar
thanks.
Everyone
thank.