►
From YouTube: Hacking Cloud Native applications through Open Source
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
A
Thanks
everyone
for
joining
us
today
welcome
to
the
cncf,
live
webinar
hacking,
Cloud
native
applications
through
open
source,
I'm,
Libby,
Schultz
and
I'll,
be
moderating
today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
I'll
hand
over
to
Arthur
oliarsh
security
researcher
with
Palo
Alto
networks.
A
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee,
but
there's
a
chat
box
on
the
side
feel
free
to
add
and
drop
your
questions
there
throughout
the
webinar
and
we'll
get
to
as
many
as
we
can.
A
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
code
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
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
at
community.cncf.io,
under
online
programs
they're
also
available
via
your
registration
link
you
use
today
and
also
on
our
online
programs.
B
B
My
name
is
Arthur
liarsh
and
I'm,
a
security
researcher
for
Palo
Alto
networks,
one
of
the
things
that
I
enjoy
I
do
the
most
is
I
like
to
look
at
different
kind
of
projects
which
mostly
open
source
project
and
I
like
to
peek
into
the
code
and
look
into
what
the
developers
might
do
wrong
and
how
could
I
exploit
it
and
Target
application,
which
are
using
this
code
in
those
packages
or
modules
so
and
today
I'm
going
to
talk
about
a
bit
about
the
security
in
Cloud
native,
open
source
projects.
B
B
Our
agenda
for
today
would
be,
firstly,
we're
going
to
go
on
a
very
high
level
on
why
applications,
why
organizations,
shifting
their
applications
to
the
cloud
and
how
they
Shifting
the
services
to
the
cloud?
What
is
the
open
source
software
role,
which
helps
them
to
achieve
this
goal?
Also,
we
will
take
a
look
at
some
of
the
challenges
and
concerns
organization
might
have
when
shifting
the
application
to
the
cloud
I.
B
Observed
in
open
source,
Cloud
native
world
and
show
you
even
some
examples
on
how
I
can
use
some
of
the
vulnerabilities
to
attack
an
application
which
is
running
within
the
cloud.
We're
going
to
talk
about
how
we
can
reduce
the
risk
and
mitigate
against
this
attacks
even
early
in
the
developing
life
cycle.
B
A
B
Get
started
why
organization
choosing
to
move
their
application
or
services
to
the
cloud.
So
there
is
a
lot
of
reasons
to
do
so,
and
I
decided
to
briefly
go
over
some
of
the
reasons.
So
it
depends
on
how
big
your
organization
is.
It
may
reduce
you
some
costs
when
you're
running
your
service
or
application
into
the
in
the
cloud.
You
don't
need
to
maintain
a
server
form.
You
don't
need
to
also
maintain
an
I.T
staff
which
is
taking
care
of
all
the
service
right,
which
is
quite
trivial.
B
Also,
you
don't
need
to
rent
a
physical
space
where
you
will
place
all
the
service
and
I.T
staff
and
will
save
some
money
on
energy,
which
always
does
consuming
endurance
scalability.
You
want
that
your
ID
infrastructure
will
adopt
your
business
needs,
for
example,
if
you're
planning
to
double
the
amount
of
users
you
have.
B
So
if
your
service
is
based
on
the
cloud
when
your
database
needs
to
grow,
you
just
space,
you
go
for
more
storage
and
you
get
it
immediately
and
you
don't
need
to
build
before
ahead
of
the
time
a
new
data,
storage
or
database
or
servers.
B
And
you
don't
know
if
you're
ever
going
to
use
it
fault,
tolerance,
which
means,
if
one
of
the
components
fails.
You
will
have
immediately
a
backup
available
within
seconds
if
you're
running
your
service
on
the
cloud
and
you
don't
need
to
maintain
a
physical
copy,
which
is
another
data
center
somewhere
of
your
service,
which
costs
you
additional
amount
of
money.
B
You
just
want
to
use
your
backup
and
when
you
need
it
and
pay
for
it
in
terms
of
performance
and
regulations,
you
want
to
be
as
close
as
possible
to
your
audience
and
clients
and
cloud
service
providers.
They
have
a
lot
of
servers
across
the
globe
and
this
is
how
the
performance
can
be
improved
because
all
the
service
are
located
in
in
countries
where
your
clients
are
so
like
how
our
organizations
are
achieving
those
goals,
how
they
start
planning
and
shifting
to
the
cloud.
B
B
A
B
It
within
the
cloud,
the
second
approach
is
revise,
which
basically
means
that
you
maybe
want
to
take
a
small
portion
of
your
application
and
adjust
it
to
benefit
from
the
cloud
provided
Services
what
they
have
to
offer.
Maybe
you
want
to
move
your
storage
to
the
cloud,
for
example,
and
the
third
approach
would
be
a
refactor
where
you
are
refactoring
an
application
to
run
on
the
cloud
providers
infrastructure,
so
you
could
benefit
from
more
services
that
they
have
to
offer.
B
The
fourth
method
is,
in
my
opinion,
more
of
a
cloud
native
approach,
which
means
that
you
rebuild
your
application
from
scratch,
you're
taking
all
of
your
code,
and
you
rewrite
your
code.
So,
like
you
building
a
new
architecture
of
how
your
application
is,
will
look
on
the
cloud.
B
So,
basically,
you
are
building
for
the
cloud
in
the
cloud,
and
this
is
the
place
where
open
source
software
tools,
Cloud
native,
open
source
software
tools-
really
it
can
come
in
handy
being
coiled
because,
like
you
are
going
to
look
for
new
Solutions,
and
sometimes
you
don't
have
the
time
to
build
your
own
cloud
native
solution
from
scratch.
Who
will
be
your?
So.
B
Into
some
open
source
software
available
people
out
there,
the
the
fifth
approach
I
didn't
mention
here,
and
it
calls
replace
or
repurchase,
which
basically
means
that
you
take
your
application.
You
put
it
aside
and
you
buying
a
new
application
software
as
a
service
which
is
will
run
on
the
cloud
and
made
for
the
cloud.
B
So
let's
take
a
look
at
what
our
open
source
software
role
with
this
with
all
this
immigration
process,
so,
first
of
all,
using
open
source
will
reduce
your
costs,
because
now
your
development
teams
will
need
to
find
new
solutions
to
new
problems
and
adopt
your
application
to
to
be
a
cloud
native.
So
in
terms
of
development,
they
don't
need
to
build
a
whole
new
solution
from
scratch.
They
just
find
the
right
tool
and
they
adjust
it
to
your
needs.
B
You
also
don't
need
to
pay
for
a
licenses
for
open
source
software
right,
so
it
reduces
some
of
the
costs
and
because,
like
your
teams,
don't
need
to
build
a
new
solution
from
scratch.
It
saves
some
time.
As
we
know,
time
is
money
today,
right,
it's
platform
neutral,
which
is
very
important.
In
my
opinion,
when
you're
building
a
solution
with
open
source
software,
you
can
run
it
on
any
platform.
So,
let's
say
you're
running
your
service
on
some
provider
X,
and
you
want
to
switch
later
to
provide
your.
B
Why,
for
some
reasons,
you
don't
need
to
rebuild
your
application
or
readjust
it,
because
your
application
is
ready
to
go
on
any
platform.
This
is
a
really
cool
feature
to
be
a
platform
neutral
Innovative.
B
In
my
opinion,
people
who
are
participating
in
building
new
Solutions
and
sharing
it
with
the
community
they're
looking
to
solve
creatively
some
existing
problems,
and
they
do
it
sometimes
in
a
really
brilliant
way
and
they
share
it
with
the
community
and
all
the
software
becomes
available
to
everybody.
So
you
really
benefit
from
Cutting
Edge
Solutions
free
to
use.
B
There
are
different
solutions
to
the
same
problem,
so
you
have
a
different
tools
which
which
basically
solve
the
same
problem,
and
you
just
need
the
one
which
will
suit
you
so
you're,
just
not
having
one
solution
for
some
problem
right.
Also,
it
maintained
by
people
from
cloud
native
Community
where
Cloud
Technologies
is
not
something
new
to
them,
and
this
is
where
I
find
it
really
in
educational
because,
like
when
your
developers
start
to
starting
that
learning
curve,
developing
their
applications
for
to
be
Cloud
native.
For
example.
If
you
are
using.
B
B
You
open
an
issue,
and
you
ask
a
question,
and
sometimes,
and
some
people
from
the
community
or
even
the
maintainers
will
start
to
try
to
answer
it
or
or
people
who
already
saw
or
had
the
same
issue
will
give
you
an
answer
that
will
can
help
you,
which
and
all
of
that
together
makes
the
application
migration
to
the
cloud
user
and
faster,
so
I
saw
some
really
cool
research
that
was
done
by
Cloud
native
Computing
Foundation,
where
they
asked
some
people
from
a
lot
of
organization
if
they
are
adopting
a
cloud
native
open
source
projects
within
on
on
production
or
they
thinking
to
using
it.
B
Maybe
they
have
some
something
or
staging
they're
testing
it
and
the
numbers
are,
are
really
really
high.
As
you
can
see,
kubernetes
is
adopted
by
96
of
the
people
who
answered
the
survey,
which
is,
in
my
opinion,
crazy.
Also,
I
think
that
the
numbers
here
are
going
to
be
higher
with
the
following
years,
because
more
and
more
organization
will
shift
part
of
their
services
or
all
of
their
services
within
to
the
cloud.
B
So
are
there
any
challenges
and
concerns
that
organization
having
when
they're
trying
to
shift
their
applications
to
the
cloud?
So
this
kind
of
a
trivial
question,
because
there
are
a
lot
of
challenges
and
concerns-
and
let's
say
it's
just
complex
because
now
your
development
team
need
to
rebuild
your
application
from
scratch
and
they
are
trying
to
ask
a
lot
of
questions
and
start
like
a
a
learning
curve.
They
raising
a
lot
of
questions
like
okay.
B
What
is
a
kubernetes
cluster?
What's
its
Anatomy?
How
should
I
containerize
my
application?
How
microservices
need
to
communicate
between
each
other?
What
are
role-based
access
controls?
What
service
measure
we
apply,
what
orchestration
tool
we
need
to
choose,
and
all
of
this
questions
have
answers
out
there
so
online.
There
is
tons
of
resources
today,
where
you
can
read
and
start
building
something,
but
to
take
all
of
these
pieces,
that's
available
out
there
and
bring
it
together
to
make
a
working
solution.
B
Will
take
a
lot
of
time
which
can
slow
down
development
process
so
lack
of
proper
training.
We
were
really
slowed
down
a
develop
development
process
and
this
is
where,
like
sometimes
you
start
to
think
or
or
maybe
question
yourself.
Maybe
I
need
to
hire
new
staff,
which
is
more
Cloud
native,
oriented
and
stuff
like
that.
So
also
it's
hard
to
choose
the
right
tools,
because
there
are
a
lot
of
Open
Source
tools
available
out
there
and
you
don't
know
which
one
best
will
suit
your
needs,
which
is
also
takes
a
lot
of
research.
B
All
of
this
right
is
also
a
lot
of
security
concern
concerns,
and
actually
there
is
a
cool
survey
again
down
by
Cloud
native
Computing
Foundation,
where
they
ask
organization
about
Cloud
native
security
concern
they
have,
and
one
I
want
to
mention
here
is
a
vulnerability
management
one.
Basically,
let's
say
you
build
an
application
already,
you,
maybe
you
have
it
on
staging
or
even
a
production,
and
let's
say
you
apply
it.
B
Some
security
update
to
your
application
or
service,
and
you
scan
the
images
you
scan
your
dependencies
and
now
you
have
a
bunch
of
vulnerabilities
going
on,
whereas
compliance
issues
and
vulnerabilities
and
packages
you're
using-
and
you
have
like
a
long,
long
list
of
vulnerabilities
and
you
just
need
to
solve
them
one
by
one.
So
you
kind
of
need
to
prioritize
all
those
vulnerabilities
and
address
those.
So
this
is
not
a
trivial
question
which
vulnerability
should
I
fix.
First,
because
fixing
vulnerabilities
it's
very
time
consuming
and
doing
in
the
right
way.
It's
very
hard.
B
B
Management
is
a
very,
very
hard
task
to
do,
and
this
is
I'm
not
surprised
why
it's
like
on
top
of
the
list.
Also
in
other
thing,
which
caught
my
eye
is
that
our
organization
been
asked
about
security
incidents,
which
is
cloud
native
related,
so
almost
50
percent
answered
that
they
prefer
not
to
disclose.
B
So
what
we'll
learn
from
it,
we'll
basically
learn
from
it
that
there
was
that
pretty
much
higher
percent
that
that
there
was
a
security
incident,
but
they
don't
want
to
talk
about
it
and
the
second
one
is
the
vulnerability
exploited,
which
we
will
talk
about
today
and
I
see
this
very
important,
because
when
you're
applying
new
technologies
and
new
tools,
you
are
using
open
source
packages
and
modules,
you
may
be
using
a
a,
not
updated
version.
Maybe
you
are
using
a
default
configuration.
B
You
can
misuse
many
things
and
many
things
can
go
wrong
and
expose
your
bigger
application
and
services
to
security
breaches
and
attacks.
So
let's
take
a
look
at
vulnerabilities
which
are
reserved
in
open
source
and
what
they
are
and
what
types
of
vulnerability
is
there.
B
So
what
I
did
I
took
a
list
of
very
known
projects
by
Cloud
native
Computing
Foundation,
which
consists
of
more
than
100
projects
and
I
searched
for
nvd
database
and
for
a
GitHub
repository
GitHub
advisories,
to
see
how
many
vulnerabilities
can
I
find
so
I
found
out
that
between
2021
to
2022
there
were
164
vulnerabilities
registered
so
and
I
tried
to
to
put
them
into
groups
by
type,
and
we
can
see
that
there
is
three
groups
which
are
really
catching
RI.
One
of
one
of
them
is
like
the
night
of
service
vulnerabilities.
B
Second,
one
is
code
execution
and
directory
traversal,
where,
where
we're
looking
at
directory,
traversal
and
code
execution
vulnerabilities
are
almost
always
High
to
critical
severity,
and
you
never
want
that.
Your
application
will
be
exposed
to
one
of
those
vulnerabilities
right.
So
I
also
think
that
if
we
will
expand
This
research
to
all
of
the
cloud
native
open
source
software,
the
number
will
be
very
high.
And
it's
not
like
means
that
I
I
think
like,
for
example,
I
see,
I
saw
some
Rising
numbers
between
2021
to
2022
and
I.
B
Think
the
numbers
are
getting
higher
as
a
security
awareness,
getting
more
attention
in
the
cloud
native
landscape.
B
So
I
was
thinking
how
hard
is
to
pick
some
vulnerabilities
from
the
list
that
I
found
to
see
and
how
some
application
could
be
attacked.
So
I
pick
up
some
vulnerabilities
from
the
list
that
I
want
to
share
with
you
and
show
how
some
application
running
within
the
cloud
can
be
attacked
by
with
them.
So
let's
see
some
examples,
so
let's
say
we
have
a
microservices
application
running
without
kubernetes
cluster
and
we
have
two
Services.
One
is
a
public
service
and
one
is
a
secret
service.
B
We
have
an
envoid
proxy
which
is
handling
our
Ingress
traffic
and
navigating
whether
to
the
public
service
or
the
Secret
Service,
with
some
access
policy
applied.
Also,
we
have
a
continuous
delivery
solution,
which
is
a
Argo
CD,
which
is
a
continuous
delivery,
Cloud
native
solution,
and
let's
say
that
Envoy
proxy
is
not
up
to
date
and
it's
containing
non-vulnerabilities
Also.
Let's
say
that
Argo
CD
is
not
up
to
date
and
Argo.
Cd
server
is
publicly
exposed
with
Anonymous
access,
enabled
just
don't
worry
about
the
anonymous
access
and
what
it
is.
B
We
will
elaborate
on
it
further
and
just
to
say
that
Anonymous
access
is
not
enabled
by
default,
but
we'll
explain
it
later.
So
in
that
in
mind,
what
can
go
wrong?
So
let
me
introduce
you
to
a
vulnerability
that
was
found
for
Envoy
proxy,
so
this
vulnerability
is
took
advantage
of
a
URL
path,
normalization.
B
So
the
way
URL
passes
treated
is
very
important
because
once
they
are
not
normalized
and
treated
well,
it
can
expose
you
for
a
different
variety
of
security
vulnerability,
one
of
which
is
the
past
reversal,
and
by
that
I
mean.
Where
is
no.
Where
is
where
there
is
no
past
normalization
in
place,
for
example,
a
relative
path
like
root
public
and
a
segment
with
double
dot
and
admin
can
trick
your
access
access
policy
in
some
systems.
B
A
double
dot
segment
means
that
you
want
to
go
to
the
powering
directory,
which
in
this
example,
means
that
you
will
simply
go
not
to
public
admin,
but
double
dot
will
go
up
to
it
to
a
Parent
Directory
which
is
root,
and
then
you
will
end
up
with
root
admin.
If
there
is
no
past
normalization
in
place,
if
we
were
applying
a
path
normalization,
it
was
ending
up
with
root
public
admin
without
the
double
dot
segment,
because
it
was
sanitized.
A
B
Then
you
were
not
granting
access
to
the
resource,
so
with
that
in
mind,
the
attack
scenario
would
be
an
attacker
would
grab
a
request
with
a
crafted
URL
containing
a
relative
relative
path
containing
double
dot
segment.
The
proxy
will
receive
this
URL
and
due
to
lack
of
path
normalization,
the
access
policy
will
be
bypassed
and
we
will
get
to
the
research
we
should
not
get
to.
B
So
an
attacker
will
send
an
HTTP
request
containing
a
crafted
URL.
Let's
say
your
shop
com,
Public
Service,
double
dot,
Secret
Service
and
when
it
will
be
parsed
by
a
proxy,
it
will
say
like
okay,
you
want
to
go
to
the
public
service,
but
where
you
want
to
reach
within
the
public
service,
let's
say
access
access
policy
is
allowing
us
to
go
whenever
we
want
within
the
public
service.
B
Access
policy,
so
if
we
will
go
into
straight
to
the
Secret
Service
by
your
shopcon
secret
service,
we
was
denied
the
access
by
the
access
policy,
but
as
simple
as
that,
using
the
double
dot
segment,
we
were
able
to
bypass
the
policy
and
get
to
the
secret
service.
So
this
is
a
classic
pass
reversal
attack.
B
Another
vulnerability
I
want
to
share
with
you.
It
was
discovered
for
Argo
CD
project
and,
more
specifically,
for
Argo
CD
server.
So
this
vulnerability
could
Elevate
privileges
taken
advantage
of
a
Json
web
token,
Authentication
and
basically
Argo
CD
trusted
invalid
claims
within
the
Json
web
token.
Basically,
Json
web
token
is
a
token
which
made
up
of
three
parts.
It
come
in
an
encoded
part
within
the
authorization
header
and
once
decoded
it
gets
the
following
structure.
It
consists
of
a
header,
payload
and
signature.
Rather
when
the
payload
contained
the
claims.
B
Claims
are
just
parameters
describing
things
about
a
user.
In
most
cases,
it's
a
user,
so,
for
example,
it
can
state
that
the
user
is
an
admin
for
how
long
this
token
is
valid
and
Etc.
So
once
Argo
CD
has
Anonymous
users
enabled
which
can
be
enabled
via
the
Argo
CD
configma
piano
file,
the
anonymous
users
will
get
the
default
raw
permission
specified
in
Argo,
CD
rabba,
config
map
and
roback
is
just
a
feature
which
is
restricts.
B
So
in
that
in
mind,
if
we
continue
reading
the
description
of
this
vulnerability,
we
will
see
that
the
attacker
will
not
need
to
have
an
account
on
Argo
CD
instance
to
explore
this
vulnerability.
Also,
he
can
impersonate
the
he
can
impersonate
a
user,
a
built-in
user,
which
is
admin
account
on
the
Argo
CD
and
once
his
escalate,
the
Privileges.
He
will
be
able
to
get
the
Privileges
the
same
privileges
on
the
cluster
as
the
argosid
instance,
which
is
by
default,
the
cluster
admin.
B
So
basically,
it
was
Fortune
a
GWT
with
some
with
Fortune
JWT
claims,
which
is
Json
with
talking
claims
which
I
talked
before,
which
I
talked
about
before
you
can
become
a
cluster
admin
which
basically
allows
you
to
delete
and
add,
or
money
or
manipulate
in
some
other
way
as
resources
on
the
cluster,
which
is
pretty
crazy.
B
So
the
attacker
will
send
a
request
with
a
forge
WT
containing
invalid
claims
and
when
Argo
CD
authentication
will
trust
the
4gwt
token,
it
will
allow
us
to
become
a
cluster
admin.
Now.
This
is
a
really
crazy
once
this
can.
If
this
can
happen,
this
is
a
really
cool
vulnerability,
also
because
Argo
CD
sometimes
receiving
and
full
information
from
some
GitHub
repository
right,
and
this
is
where
another
attack
vector
that
can
be
shown
to
the
to
the
attacker.
Now
now
he
maybe
can
later
exploit
all
of
the
CI
CD
pipeline.
B
So
another
thing
is
that
some
vulnerabilities
can
hide,
and
if
you
remember
the
first
vulnerability
that
I
introduced
to
you
is,
was
that
passed
through
our
sole
vulnerability
within
Envoy
proxy?
So
what's
so
big
deal,
so
this
vulnerability
was
first
reported
to
istio
in
February
18
by
security
researcher.
So
istio
investigated
it
further
and
they
found
out
that
the
issue
is
within
the
envoy.
Proxy
is
still.
If
someone
don't
know
it's
like
a
service
mesh
where
it
injects
Envoy
proxy
as
a
sidecar
to
each
pod
within
the
cluster.
B
So
you
see
how
it's
complex.
It
gets.
One
project
which
is
using
Android
proxy
becomes
vulnerable
because
the
other
projects
have
an
normalization
issue.
So
I
still
reported
this
issue
to
an
avoid
proxy
team
and
then
web
proxy
and
then
white
opened
publicly
available
issue
on
the
GitHub
repository
and
if
we
will
look
closely
at
the
issue
that
was
open,
so
we
a
technical
person
can
read
through
this
and
say:
hey
I
can
I
can
pretty
much
understand.
B
What's
going
on
and
I
maybe
can
try
out
and
write
some
imposter
rehearsal
exploit
for
and
see
if
it's
working
and
if
I'm,
an
attacker
and
I
know
that
my
target
is
running
a
cloud
native
proxy.
B
Even
if
I
don't
know,
if
that
in
word,
proxy
or
other
proxy
out
there
I
maybe
want
to
Target
all
the
publicly
available
Cloud
native
proxy
repositories
right
and
see
for
a
scan
for
issues
and
pull
requests
that
are
available
publicly
to
see
if
there
is
any
hints
that
can
point
out
to
some
security
weakness
which
I
might
exploit.
So
after
the
issue
was
realized
and
the
severity
was
realized
by
the
Moy
team.
They
moved
to
a
private
fix
process,
which
is
was
already
after
20
days
after
the
issue
was
pushed.
B
So
there
was
a
20
days
Gap,
so
someone
could
pick
up
an
exploit
and
if
you
do,
if
you're
thinking
that
attackers
is
this
not
enough
days
for
an
attackers
to
do
something.
So
there
was
already
a
and
not
related
to
Envoy,
but
there
was
some
stories
out
there
that
some,
some
things
escalated
less
than
two
days
so
hidden
vulnerabilities
is
whole
of
an
subject.
For
example,
the
vulnerability
I
just
talked
about
Pastor
Wilson
and
white
proxy.
B
This
issue
on
GitHub
was
available
before
even
the
CV
was
assigned
to
the
vulnerability.
So
this
is
a
really
big
subject
and
two
bodies
and
colleagues
of
mine
have
a
great
talk
for
Linux
Foundation,
which
is
called
hidden
vulnerabilities
in
open
source,
which
you
can
watch
by
typing,
this
hidden
liability
and
open
source
on
YouTube,
or
just
check
for
the
link
below
just
another
small
thing
to
add
not
always
there,
there
are
to
to
this
hidden
vulnerability
subject.
B
Sometimes
there
are
vulnerability,
but
there
is
no
cve
and
the
reason
is
that
sometimes
development
teams
are
not
aware
enough
that
what
they
fixed
was
a
security
issue
that
can
be
exploited
unless
someone
points
it
out
to
them.
So
there
are
a
lot
more
reasons
to
why
that
happens,
and
in
there
it
is
like
explained
in
the
hidden.
Morability
is
an
open
source
talk,
so
you
can
pick
and
see
more
information.
B
So
how
should
we
reduce
the
risk?
How
should
we
mitigate
as
much
as
we
can
against
those
attacks?
B
So,
first
of
all,
it
is
always
great
to
have
a
map
of
your
application
and
its
building
blocks.
You
want
to
see
which
types
of
packages
modules
or
tools
you're
using
within
your
solution,
and
then
you
want
to
check
for
updates
and
release
notes
for
those
entities
and
see
if
there
is
some
release,
notes
related
to
security
that
you
might
address.
B
Maybe
there
is
some
work
around
and
no
fix
yet
if
there
are
fixed,
maybe
you
want
to
patch
and
update
the
version
also
strongly
advise
to
go
to
a
security
advisory
of
your
of
the
projects
you
are
using.
Most
of
the
cloud
native
open
source
projects
are,
repositories
are
on
GitHub
and
GitHub
is
maintained
in
a
security
advisory.
You-
and
this
is
a
publicly
available.
B
They
have
also
API
and
you
can
search
for
a
project
you're
using
a
module
or
package
and
and
see
for
non-vulnerabilities
also
you
can
and
go
to
nvd
and
look
for
non-vulnerabilities
and
CVS
within
that
database.
Also,
there
are
a
lot
of
scanners
in
open
source
available,
so
you
can
scan
for
images
or
dependencies.
So
you
can
see
if
you're
a
direct
or
transitive
dependencies
have
some
non-vulnerabilities
right.
So,
as
you
can
see,
for
example,
we
talked
about
istio.
B
The
vulnerability
for
Envoy
proxy
was
reported
from
istio
team,
because
istio
team
is
making
use
of
envoy
so
scanning,
for
that
is
really
really
important.
Another
great
tool
is
SCA
tools.
Software
composition,
analysis
tools.
Are
there
it's
like
a
methodology
that
show
allows
you
to
track
all
of
your
open
source
modules
packages
and
tools
that
you
use
in
within
your
project
and
also
those
tools,
sometimes
really
developer
friendly.
So
you
can
think
of
how
you
can
integrate
them
into
your
CI
CD
pipeline.
B
So
you
can
wreck
Hillary
scan
for
those
dependencies
and
packages
and
modules
and
packages
and
discover
the
vulnerabilities
early
in
the
cicd
process
and
software
development
life
cycle.
Also,
those
tools
will
help
you
to
prioritize
risk.
We
should
talk
here
before
right.
So
one
of
the
issues,
great
issues
for
security
teams
or
engineering
teams,
is
that
after
scanning
for
the
vulnerabilities,
they
have
a
long
list
of
vulnerabilities.
B
So
they
need
to
know
what
to
prioritize
first
and
and
what
to
fix
first,
sometimes
it's
not
about
the
critical
vulnerability,
but
it
for
the
vulnerability
that
this
can
be
mostly
exploited
on
your
container.
For
example,
if
your
container
is
exposed
to
the
network
and
running
with
site
privileges,
even
a
medium
severity,
vulnerability
can
be
a
really
Danger.
B
B
So
if
you
remember,
for
example,
this
hidden
vulnerabilities
topic
that
I
talked
previously,
there
are
security,
research
teams
which
dedicate
the
time
to
find
those
vulnerability,
and
then
they
integrate
this
in
the
ACA
tools
and
once
you're
using
them,
you'll
get
trashed
for
those
vulnerabilities
even
before
they
get
assigned
cves,
and
this
is
how
you
can
really
really
mitigate
and
and
reduce
the
risk
from
your
application
being
exploited
or
exposed
to
cyber
attacks.
B
So
this
all
I
have
to
say
for
the
moment.
Thank
you
for
listening
and
if
you
have
any
questions,
I
would
like
to
answer
them.
Thank
you.
B
A
A
Else,
you
want
to
add
any
ways
to
contact
you
or
places
they
can
opt
in
to
find
out
more
information.
A
All
right
well,
if
no
one
has
any
more
questions
thanks
everyone
for
joining
us.
Thank
you
Arthur
for
the
presentation,
and
these
will
be
online
later
today.
The
slides
in
the
presentation
will
be
on
the
website.
So
thank
you,
everyone
for
joining
us.
Thank
you,
Archer
and
we'll
see
you
all
again.
Next
time,
yep.