►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Keynote: Supply Chain: The New Threat Vector in Cloud Native Security - Ali Golshan, Co-founder and CTO, StackRox now Red Hat
At its core, cloud native technologies are heavily dependent on community contributions and developers. As a result, the final stack of tools most organisations run in production are assembled from a series of assets that have been developed outside the organisation. The security and trust in supply chain matters now more than ever. We will discuss how the attack surface in cloud native has shifted from the traditional vectors to the supply chain as well as open source resources, and what we as a community need to do to reduce this risk.
A
A
The
other
aspect
of
it
is
that
traditional
attribution
is
substantially
more
difficult
to
apply
on
the
supply
chain
side.
As
a
result,
it
reduces
the
risk
of
discovery
and
it
can
actually
increase
the
attack
surface
as
an
attacker.
You
can
go
after.
This
is
also
why
it's
very
important-
and
this
is
why,
at
red
hat,
we
believe
it's
very
important
for
security
to
be
built
in
versus
bolted,
on
for
developer
tools
and
as
part
of
the
supply
chain.
A
Now
what
are
some
of
the
things
that
you
have
to
consider
and
be
able
to
make
sure
you
take
into
consideration
as
part
of
your
supply
chain
security?
Well,
one
major
question
is:
where
am
I:
where
do
my
software
components
come
from?
Where
am
I
getting
my
tools?
Where
am
I
getting
all
these
particular
images?
Images
and
public
registries
can
be
potentially
poisoned
with
unwanted
application,
malware
back
doors
or
potentially,
components
that
are
unuseful
to
you,
but
could
be
very
useful
for
attackers
and
for
anybody
trying
to
infiltrate
your
network.
A
In
some
cases
these
can
be
detected
with
static
tool
analysis,
and
this
is
why
it's
very
important
to
have
static
analysis.
As
part
of
your
system,
however,
introducing
a
lot
of
vanilla
images
and
ensuring
that
there's
a
large
touch
point
to
your
potentially
infected
images
can
also
ensure
that
the
deployment
of
these
images
increases
and
eventually
they
make
them
into
the
stream
of
the
development.
A
The
other
part
of
it
is
vulnerability.
Management
and
configuration
management
as
part
of
the
supply
chain
in
a
declarative
fashion
is
still
a
substantially
unsolved
problem.
The
volume
of
attacks
is
increasing
dramatically,
suggesting
that
there's
more
and
more
organized
infrastructure
and
some
targeting
of
which
companies
introduce
a
higher
level
of
tooling
into
other
companies
supply
chains.
Obviously,
this
is
an
example
that
we
recently
saw
with
the
solar
winds
attacks
combined
with
the
attribution
we
talked
about
and
the
problem
that
it
presents
on
the
supply
chain.
A
Poisoning
the
well
can
be
a
substantially
more
lucrative
way
to
attack
businesses
versus
actively
engaging
of
exploitation,
exploitation
of
vulnerabilities
at
run
time.
So
when
we
talk
about
cves,
even
though
this
is
an
unsolved
problem,
there
is
still
a
lot
of
gaps
that
we
need
to
go
and
figure
out.
So
we
need
to
pay
more
attention
to
it.
Understanding
vulnerability
packages
and
their
dependencies,
these
typically
create
thousands
of
alerts
and
there's
no
good
way
to
triage
these
understanding.
What
are
they
actually
relevant
to
which
ones
can
be
solved
or
upgraded
if
they
are
upgraded?
A
What
can
they
break?
Which
ones
are
actually
exposed
to
me
in
runtime?
Are
they
allowing
for
permissive
attack
surface?
Do
I
have
proper
configurations
to
be
able
to
prevent
them
and,
more
importantly,
which
ones
are
actually
being
exploited
into
the
wild?
So
I
can
push
that
information
back
to
my
engineers,
to
my
developers
to
reduce
that
time
in
resolving
those
particular
problems.
A
Now,
typically,
one
of
the
things
that
we
have
seen
from
supply,
chain
attacks
and
general
attacks
on
misconfigurations
really
the
way
we
can
solve
these
problems
through
a
declarative
fashion.
The
problems
have
centered
around
mostly,
for
example,
installing
cryptocurrency
miners
or
establishing
a
footprint
for
distributed
dental
service
attacks.
A
But
more
recently,
we
have
started
to
see
a
substantially
more
targeted
approach
for
supply
chain
attacks,
again
being
able
to
push
yourself
into
a
stream
where,
because
of
all
these
layers,
and
all
these
abstractions,
you
become
embedded
into
images
and
tools
and
eventually
become
part
of
the
existing
stack
which
creates
substantial
problems.
Now
you
combine
this
with
additional
problems
like
the
fact
that
more
and
more
we're
using
from
a
development
and
automation,
standpoint
infrastructure
as
code
templates,
so
whether
we're
using
things
like
hashicorp
terra,
hashicorp,
terraform,
aws
cloud
formation,
templates,
kubernetes,
app,
manifest
yamls.
A
These
are
things
developers,
use
and
devops
teams
use
to
be
able
to
move
faster,
but
at
the
same
time,
if
we
can
essentially
move
more
and
more
to
the
left
and
be
able
to
do
things
as
an
example,
tools
like,
for
example,
kube
linter,
where
we
can
actually
fix
misconfiguration
and
be
able
to
identify
some
of
these
problems
in
configuration
and
supply
chain
issues
before
they're
introduced
into
infrastructure
at
runtime,
they
present
a
much
easier
way
to
solve
these
things.
The
other
reason
why
supply
chain
security
is
very
important
is
understanding
these
deep
dependencies.
A
A
This
is
why
we
think
it's
very
important
not
just
to
have
security
for
build,
deploy
and
run,
but
it's
very
important
to
be
able
to
tie
all
these
stages
together
through
a
cohesive
policy
language
where
context
can
be
shared
and
problems
can
be
solved
based
on
actual
relevance
and
impact.
One
of
the
other
types
of
more
recent
attacks
we've
seen
on
the
supply
chain
is
actually
the
notions
of
typo
squatting,
which
is
we're
starting
to
see
a
more
rise
towards.
A
So
as
we
talk
more
and
more
about
infrastructure,
as
code
templates,
it's
very
important
to
understand
that
if
these
misconfigurations
are
introduced
into
your
infrastructure,
they
substantially
amplify
the
risk
that
goes
into
your
runtime
infrastructure
and
in
a
lot
of
cases,
these
become
embedded
in
your
infrastructure
and
very
difficult
to
roll
back.
This
is
why
you
constantly
now
hear
about
this
notion
of
shift
left
and
why
it's
very
important
to
do
that.
Now
we
recognize
at
red
hat
that
there
is
a
very
fine
balance
between
velocity
and
flexibility
for
developers.
A
Developers
want
to
be
able
to
choose
their
packages,
want
to
be
able
to
determine
which
containers
they
want
to
use
and
being
able
to
essentially
determine
how
they
build
together
their
tools
that
allow
them
to
move
faster
and
deliver
business
goals.
But
at
the
same
time
we
want
to
have
vetting
and
controls
in
place,
so
we
can
apply
compliance
whether
it
starts
from
very
basic
aspects
of
cis
benchmarks
or
more
custom,
or
very
specific,
useful
custom
tools
and
controls
that
are
specific
to
your
business
and
organization
to
be
able
to
vet
these
out.
A
The
other
reason
as
to
why
supply
chain
security
becomes
very
important
and
dealing
with
these
issues
in
a
declarative
fashion
is
not
just
the
infrastructure
itself,
but
all
the
new
layers
of
tooling
that
are
highly
automating
and
contributing
to
scale,
for
example,
going
from
kubernetes
to
istio
general
service
meshes.
These
are
all
components
that
are
highly
contributing
to
the
velocity
of
development.