At
the
recent
CloudNativeSecurityCon
in
Seattle,
800
DevSecOps
practitioners
gathered
to
address
a
myriad
of
software
supply
chain
security
issues,
including
the
security
of
container
images
and
the
impact
of
zero
trust
on
the
software
supply
chain.
As
of
last
year,
there
were
7.1
million
cloud-native
developers,
51%
more
than
the
4.7
million
12
months
earlier,
Cloud
Native
Computing
Foundation
executive
director
Priyanka
Sharma
said
in
the
opening
keynote.
“Everyone
is
becoming
a
cloud-native
developer,”
Sharma
said.
However,
this
rapid
shift
to
cloud-native
development
can
be
a
source
of
concern,
since
the
rapid
release
cycles
may
lead
to
organizations
not
following
secure
lifecycle
development
(SDLC)
practices,
Sharma
warned.
Snyk’s
2022
State
of
Cloud
Security
report
found
that
77%
of
organizations
acknowledged
that
they
have
poor
training
and
lack
effective
collaboration
among
developers
and
security
teams.
“There
are
siloed
teams
often
working
in
separate
countries,
time
zones,
using
different
tools,
policy
frameworks,”
Sharma
said.
“In
the
cloud-native
environment,
we
are
interacting
with
so
many
other
entities.
Throw
in
a
lack
of
security
policy,
and
there’s
the
recipe
for
your
security
breach.”
The
lack
of
security
policies
is
fueling
an
increase
in
vulnerabilities
due
to
misconfigurations.
An
alarming
87%
of
container
images
running
in
production
have
critical
or
high-severity
vulnerabilities,
up
from
75%
a
year
ago,
according
to
the
Sysdig
2023
Cloud-Native
Security
and
Usage
Report.
Yet
only
15%
of
those
unpatched
critical
and
high
vulnerabilities
are
in
packages
that
are
in
use
at
runtime
where
a
patch
is
available.
Sysdig’s
findings
are
based
on
telemetry
gathered
from
thousands
of
its
customers’
cloud
accounts,
amounting
to
billions
of
containers.
The
high
percentage
of
critical
or
high-severity
vulnerabilities
in
containers
is
the
outgrowth
of
the
rush
by
organizations
to
deploy
modern
cloud
applications.
The
push
has
created
an
influx
of
software
developers
moving
to
the
more
agile
continuous
integration
continuous
development
(CI/CD)
programming
model.
Sysdig’s
report
recommended
filtering
to
isolate
only
the
critical
and
highly
vulnerable
packages
in
use
in
order
to
focus
on
packages
that
present
the
most
risk.
Further,
only
2%
of
the
vulnerabilities
are
exploitable.
“By
looking
at
what
has
in
use
exposure,
that
is
what
is
actually
in
use
at
runtime,
and
having
the
fix
available
will
help
teams
prioritize,”
Sysdig
threat
researcher
Crystal
Morin
wrote
in
the
report.
5
Elements
of
Zero
Trust
Implementation
Sharma
pointed
to
last
year’s
Cost
of
a
Data
Breach
report
from
IBM
and
Ponemon
Institute,
which
showed
that
79%
of
organizations
have
not
moved
to
a
zero-trust
environment.
“That
is
really
not
good,”
Sharma
said.
“Because
almost
20%
of
breaches
are
occurring
because
of
a
compromise
at
a
business
partner.
And
keep
in
mind
that
almost
half
the
breaches
that
occur
are
cloud-based.”
A
key
barrier
to
instituting
zero
trust
is
environments
where
permissions
are
not
under
control.
According
to
the
Sysdig
report,
90%
of
permissions
granted
are
not
used,
creating
an
easy
path
for
stealing
credentials.
According
to
the
report,
“teams
need
to
enforce
least
privilege
access,
and
that
requires
an
understanding
of
which
permissions
are
actually
in
use.”
Zack
Butcher,
founding
engineer
at
Tetrate
and
an
early
engineer
on
Google’s
service
mesh
project
Istio,
said
creating
a
zero-trust
environment
isn’t
that
complicated.
“Zero
trust
itself
isn’t
a
mystery,”
Butcher
told
attendees.
“There’s
a
lot
of
FUD
[fear,
uncertainty,
and
doubt]
around
what
zero
trust
is.
It’s
fundamentally
two
things:
people
process
and
runtime
controls
that
answer
and
mitigate
the
question,
‘what
if
the
attacker
is
already
inside
that
network?'”
Butcher
identified
five
policy
checks
that
would
make
up
a
zero-trust
system:
-
Encryption
in
transit
to
ensure
messages
can’t
be
eavesdropped -
Service
level
identity
to
enable
authentication
at
runtime,
ideally
a
cryptographic
identity -
The
ability
to
use
those
identities
to
be
able
to
perform
runtime
service-service
authorization
to
control
which
workloads
can
talk
to
each
other -
Authenticating
the
end
user
in
session -
A
model
that
authorizes
the
actions
users
are
taking
on
resources
in
the
system
Butcher
noted
that
while
these
are
not
new,
there
is
now
an
effort
to
create
an
identity-based
segmentation
standard
with
the
National
Institute
of
Standards
and
Technology
(NIST).
“If
you
look
at
things
like
API
gateways
and
ingress
gateways,
we
do
these
checks
usually,”
he
said.
“But
we
need
to
be
doing
them,
not
just
at
the
front
door,
but
every
single
hop
in
our
infrastructure.
Every
single
time
anything
is
communicating,
we
need
to
be
applying,
at
minimum,
these
five
checks.”
NIST
Standard
Coming
Up
During
a
breakout
session,
Butcher
and
NIST
computer
scientist
Ramaswamy
“Mouli”
Chandramouli
explained
the
five
controls
and
how
they
fit
into
a
zero-trust
architecture.
Tools
such
as
a
service
mesh
can
help
implement
many
of
those
controls,
Butcher
said.
The
presentation
is
an
outline
for
a
proposal
that
will
be
presented
as
NIST
SP
800-207A:
A
Zero
Trust
Architecture
(ZTA)
Model
for
Access
Control
in
Cloud
Native
Applications
in
Multi-Location
Environments.
“We
expect
to
have
this
out
for
initial
public
review
sometime
in
June,”
Butcher
said.
Butcher
said
supply
chain
security
is
a
critical
component
of
a
zero-trust
architecture.
“If
we
can’t
inventory
and
attest
what’s
running
in
our
infrastructure,
we
leave
a
gap
for
attackers
to
exploit,”
he
said.
“Zero
trust
as
a
philosophy
is
all
about
mitigating
what
an
attacker
can
do
if
they
are
in
the
network.
The
goal
is
bounding
their
attack
in
space
and
time,
and
controlling
the
applications
that
execute
in
that
infrastructure
is
a
key
element
of
bounding
the
space
an
attacker
has
to
work
with.”
About Author
