►
From YouTube: OpenShift Commons Briefing: Securing OpenShift DevOps Pipelines w/ Andrei Bezdedeanu (Cybric.io)
Description
The CYBRIC platform integrates seamlessly into the DevOps process on OpenShift and enables continuous scanning capabilities at every stage. As code gets written and committed to code repositories, as build processes complete, CYBRIC can submit the code or build artifacts to scanning by a variety of open source and commercial SAST and SCA tools. The platform provides a unified integration to all products, which lowers the barriers for adoption and potential switching costs. Similarly, container images can be scanned as soon as they are built or posted to repositories such a Docker Hub, Artifactory or Nexus.
Within an OpenShift environment CYBRIC discovers and automatically scans all applications deployed, as well as the published external routes, with a range of DAST open source or commercial products. As new applications get deployed or new routes created, CYBRIC can detect them, automatically create new targets and scan them immediately for any vulnerabilities or misconfigurations. Scan results from the entire security toolchain are collected, normalized and deduplicated in order to provide the most concise and accurate view of the customer’s Security Posture at an application level. Static and dynamic scan results are correlated to provide valuable information about the most critical vulnerabilities as well as point out the root causes of the exploits observed against the applications.
CYBRIC Dashboards present data relevant to the executive level as well as for application stakeholders and individual contributors. Ultimately, the platform provides a clear view of Application and Enterprise Risk and helps users answer key business questions regarding the security and quality of the applications within the enterprise.
A
Hello,
everybody
and
welcome
again
to
another
openshift
Commons
briefing.
Today
we
have
another
new
open,
Commons
them.
Member
of
cyber
they've
just
recently
joined
though
they've
been
working
on
their
integration
with
open
ship
for
quite
a
while,
not
quite
a
while,
but
for
a
while
and
they're
gonna
tell
us
a
little
bit
about
that
in
a
talk
called
securing
a
DevOps
open
ship
pipeline,
Andre
and
Sergei.
Thank
you
very
much
for
joining
us
today,
I'm
gonna.
Let
you
both
introduce
yourselves
the
format
for
this.
As
always,
is
ask
your
questions
in
the
chat.
A
B
Thank
You
Diane,
so
I'm
gonna
start
with
my
introduction.
Then
I'll
pass
it
off
to
Stargate
for
his
I'm.
The
VP
of
engineering
at
SCI
break
I've
been
with
a
company
since
July
2016
I
am
based
in
Boston
Massachusetts,
where
our
company's
headquarters
and
my
main
focus
is
platform
architecture,
I'm
working
on
building
and
expanding
our
ecosystem
of
partners
and
I
work.
I'm
very
involved
in
the
early
customer
experience.
C
So
my
name
is
Sergei
Baruch
and
I'm,
director
of
engineering
inside
break
in
a
moose
habit
since
February
last
year.
In
the
again,
my
main
focus
is
on
extending
platform
architecture
making
sure
we
can
satisfy
all
the
needs
of
our
customers
and
also,
as
our
God
firm
targets
like
companies
with
the
right
variety
requirements
of
and
approaches.
C
B
Thank
you.
So
let's
talk
a
little
bit
about
sigh
break,
I'm,
not
sure.
If
many
of
you
know
about
us,
we
are
a
boston-based
startup
and
our
mission,
and
our
goal
is
to
enable
our
customers
to
fully
integrate
and
automate
security
throughout
the
development
lifecycle
and,
and
that
starts
from
that
day.
B
A
developer
writes
the
first
line
of
code
and
convince
it
to
the
code
repository
through
the
build
process
through
a
CI
ICD
pipeline
and
and
also
as
applications
are
being
deployed
into
non
production
and
eventually
production
environments,
and
our
goal
is
to
not
only
integrate
an
embedded
security
into
this
process,
but
do
so
without
a
significant
impact
to
the
production
environment
or
really
to
the
developers
workflow
stuff.
We're
looking
for
seamless
integrations
as
much
as
possible.
B
The
reason
we
built
this
platform
is
because
we've
noticed
that
there
are
simple
challenges
with
a
current
approach
to
application
security.
These
challenges
range
from
the
fact
that
traditionally
many
companies
have
that
even
that
have
adopted.
Devops
strategies
and
cultures
still
have
a
separation
between
DevOps
and
sec.
Ops
and
the
security
team
is
always
separated,
not
just
physically
but
but
in
many
ways
from
the
development
team.
B
So
that
usually
creates
a
lot
of
friction
in
many
cases.
We
also
recognize
that
that
many
of
our
customers
and
potential
customers
are
already
doing
something
about
security.
They
have
a
number
of
tools
in
place.
In
many
cases
they
have
combinations
of
both
commercial
and
open
source
tools,
and
they
are
usually
owned
by
different
teams.
Different
individuals,
different
groups
altogether
and
there
isn't
a
lot
of
collaboration
between
those
teams
and
what
they're
missing
out
on
is
recognizing
that
there
are
both
gaps
and
overlaps
in
the
tooling.
B
B
In
many
cases,
the
approach
to
security
testing.
It
is
periodic,
sometimes
infrequent
it's
done,
based
on
application
delivery
schedules.
It's
done.
It's
certain
points
in
the
development
or
deployment
process,
and
that
tends
to
be
expensive.
It
tends
to
be
a
mini
project.
Every
time
it
happens
where
people
are
pulled
from
their
their
regular
jobs
in
order
to
either
participate
or
to
react
to
issues
that
are
being
found,
but
but
in
between
scans,
a
lot
lots
of
things
can
happen.
Finally,
the
abilities
can
get
introduced.
B
Many
times.
We
noticed
that
there
is
a
not
just
a
learning
curve
from
a
development
teams
perspective
in
order
to
learn
about
development,
about
security
tools,
static
analysis
tools,
composition,
analysis
tools,
but
but
sometimes
go
into
that
curve
and
starting
to
take
steps
to
scan
their
code
and
their
build
artifacts
and
their
containers
is
disruptive
to
the
development
velocity,
especially
in
organizations
where
they
take
on
an
agile
approach
and
then
use
scrum
methodologies.
B
This
becomes
disruption
to
that
velocity.
Ultimately,
because
this
is
not
a
generally
a
comprehensive
program
or
framework
companies
are
missing
out
on
the
visibility
they
can
have
at
a
high
level
at
a
business
ownership
level.
At
a
you
know,
from
a
stakeholder
perspective
or
from
a
sea
level
executive
perspective
to
truly
understand
their
risk
and
application
at
enterprise
level
and
they're
missing
out
on
a
number
of
metrics
and
KPIs
that
it
can
have
access
to
in
order
to
improve
their
operations,
to
improve
their
risk
and
to
improve
their
processes
overall.
B
There
is
a
way
you
can
adopt
a
standard
platform
to
make
it
seamless
for
you
to
embed
security
into
your
software
development
lifecycle
and
ultimately
reduce
your
risk
from
from
a
cyber
perspective.
So
some
of
the
things
that
we
do
and
I
will
talk
about
these
in
more
detail
a
little
bit
later.
Is
we
enable
customers
to
be
proactive
and
we
talk
about
shifting
left,
which
really
means
embedding
security
tools,
processes
and
best
practices
into
the
DevOps
process.
We
provide
a
central
administration
component
to
the
tools
that
you're
using.
B
We
are
not
a
scanning
tool.
We
do
not
make
scanning
tools.
We
are
a
platform,
that's
focusing
on
orchestration
automation
that
allows
you
to
plug
into
it
of
both
open
source
and
commercial
tools
that
either
you
already
have,
or
that
you'd
like
to
introduce
within
your
organization
and
again,
these
range
from
static
analysis
tools
to
composition,
analysis
to
container
security
tools,
to
dynamic
scanning
tools,
to
automated
pen,
testing
and
so
on.
So
we
make
that
process
easy.
B
We
make
sure
that
we
stay
away
of
any
breaking
changes
to
those
vendors
are
putting
in
place
in
order
to
really
ensure
that
that
you
don't
feel
the
pain
of
that,
but
but
we
also
give
you
a
unified,
a
single
interface
to
to
interact
with
all
these
tools
so
by
simply
specifying
which
tool
you
want
to
use
in
which
configuration
of
the
tool
you
can
interact
with
them
the
same
way.
So
you
don't
have
to
learn
about
their
specific
api's,
workflows
and
command
line.
You
know
differences
and
so
on.
B
I
talked
about
seamless
integration
into
the
stuff.
At
the
point
of
lifecycle,
we
do
that
in
a
number
of
ways.
We
use
sensible
triggers
as
much
as
possible.
We
try
to
use
web
hooks
at
the
repository
level
so
that
uncommit
we
can.
You
can
get
copies
of
the
code
and
submit
them
for
scanning
or
pull
requests.
B
We
try
to
add
steps,
sensible
steps
in
your
build
pipeline
so
that,
at
the
end
of
the
build
process,
the
build
artifacts,
the
output
of
the
build
process
can
be
submitted
for
scanning,
as
appropriate
as
applications
are
being
deployed
by
your
deployment
systems.
We
hook
in
at
that
level,
so
through
either
triggers
or
other
sensible.
B
Mechanism
we
can
get
notified
of
those
actions
and
we
can
start
scanning
the
newly
deployed
applications
immediately
then
I
will
talk.
We
will
talk
in
more
detail
about
how
we
do
this
in
an
open,
shipped
environment
course.
Ultimately,
we
collect
all
the
data
from
the
very
scanning
tools
we
bring
into
our
platform
and
we
make
sense
of
it.
We
provide
powerful,
analytics
and
metrics
that
you
can
leverage
to
get
this
high-level
view
of
everything
that's
going
on
within
your
within
your
environment.
So
again
the
approach
there
are
just
a
couple
of
components
to
our
approach.
B
Automation,
orchestration
is
our
bread
and
butter
we've
automated
the
scans
and
we
were
constrain
the
entire
process.
We
integrate
with
a
fair
amount
of
scanning
tools,
both
open
source
and
commercial,
and
that
ecosystem
of
integration
is
is
increasing
practically
every
week
we
provide
you
visibility
and
assurance
visibility
into
the
vulnerabilities,
the
the
risk
at
the
application
level
any
correlations.
It
can
kpi's
an
assurance
that
this
is
running
on
a
continuous
basis.
It
doesn't
require
people
to
execute
manual
commands.
B
It
allows
you
to
institutionalize
that
the
tools
and
the
frameworks
that
he
used
to
scan
your
code
and
applications
and
environment
it
allows
you
to
ensure
that
that
this
operates
continuously
and
only
get
notified
of
specific
relevant
events
that
occur
within
within
that
world.
So,
let's
talk
a
little
bit
about
how
this
actually
works.
We're
gonna
start
off,
as
I
said,
with
the
developer
writing
code
and
committing
it
to
a
source
control
repository,
whether
it's
github
bitbucket
could
have
enterprise
SP,
and
it
doesn't
matter.
B
At
the
end
of
the
day,
we
integrate
with
many
source,
controlled
repositories
and
again
we
use
for
the
most
part
tools
like
like
web
hooks
in
order
to
get
notified
of
specific
actions
of
interest.
Like
code
commits
like
pull,
requests
and
things
like
that
and
upon
receiving
those
notifications,
we
will
reach
out
to
their
respective
code
repositories.
B
We
will
pull
a
copy
of
the
code
and
submit
it
for
scanning,
either
static,
application
scanning
or
stopped
a
composition
analysis,
and
we
will
do
so
with
one
of
the
tools
they've
already
integrated
with
we
add
again,
new
integrations
all
the
time.
So
if
there's
something
you
don't
necessarily
see
on
this
list,
this
is
just
a
representative
sample.
These
are.
This
is
a
listed
that's
ever-changing
and
ever-growing
this
does
beyond
that
initial
set
up.
B
This
does
not
require
the
developer,
to
do
anything
specific
that
they
can
each
specific
steps
in
terms
of
manually
having
just
to
make
their
code
for
scanning.
It
simply
works
as
a
background
task.
They
can
I,
certainly
use
our
platform
to
get
visibility
to
the
results,
but
they
can
also
get
notified
via
email
via
slack
when
any
new
issues
are
detected
or
any
existing
issues
are
remediated
think
we
can
also
open
tickets
in
their
insular
management
system,
whether
they
use
JIRA,
whether
your
ServiceNow
or
something
else.
B
We
have
the
ability
to
open
tickets
in
those
systems
and
leverage
their
existing
tools,
their
existing
DevOps
processes.
In
order
to
get
notifications
of
these
new
vulnerabilities
that
are
being
detected
beyond
that,
there's
typically
a
build
process,
whether
that's
with
a
tool
like
Jenkins
or
something
else,
but
we
have
the
ability
to
integrate.
With
with
most
of
these
platforms
through
a
generic
add-in
that
that's
docker
based,
we
can
insert
steps
in
those
cncd
pipelines
at
various
stages.
B
After
the
code
check
out
again,
we
can
insert
a
step
to
get
a
copy
of
that
code
and
submit
it
for
scanning.
After
code.
After
the
build
process,
we
can
take
a
copy
of
the
build
artifact.
The
jar
files,
the
executables
dll's,
whatever
it
is,
and
submit
those
for
scanning
for
binary
analysis
and
also,
if
applicable,
on,
is
used
to
deploy,
applications
or
to
build
containers.
We
can
also
scan
the
container
images
that
are
created.
B
We
can
submit
them
for
scanning
with
the
appropriate
tools
or
we
can
run
a
dynamic,
getting
tool
against
the
deployed
instance
of
the
application.
So
again,
once
once,
the
scan
images
are
built,
whether
they
are
put
in
an
artifact
or
image
repository
like
like
docker
hub
Nexus
or
the
factory,
or
whether
they're
pushed
directly
to
an
open,
shipped
container
registry
in
your
open,
shipped
environment,
we're
able
to
again
immediately
upon
creation
or
publishing,
obtain
those
those
images
and
submit
them
for
scanning,
with
tools
like
Claire,
aqua,
twistlock
and
so
on.
B
B
Let's
talk
about
the
overshift
environment
for
a
minute,
so
our
integration
with
open
shipped
as
Diane
mentioned
at
the
beginning
of
this
call,
is
a
reasonably
new
addition
to
our
suite
of
integrations
and
the
way
we
integrate
with
open
shift
is
again
following
the
same
methodology
as
everything
else.
We
try
to
provide
a
seamless
integration
to
your
non
production
and
production
environments
as
such
as
images
as
as
docker
images
are
being
staged
as
they're
being
deployed
and
and
spun
up
as
applications
as
new
routes
are
being
made
available.
B
As
external
endpoints,
we
have
the
ability
to
monitor
for
all
those
events,
in
your
open
shift,
environment
and
and
upon
receiving
those
events.
Our
platform
will
take
the
appropriate
action
to
automatically
create
that
the
target,
the
representation
of
the
target
in
our
platform
to
set
up
the
appropriate
process.
B
As
external
you
know,
attack
vectors
or
internally
inside
those,
those
no
nodes,
there's
open
ship
nodes
to
provide
a
view
of
what
the
internal
risks
might
be.
In
this
case,
we
have
the
ability
to
also
scan
the
underlying
infrastructure,
whether
it's
running
in
a
VMware
environment
where
the
OpenShift
has
been
deployed
in
a
VMware
environment
or
whether
it's
been
deployed
as
on
top
of
a
cloud
provider.
B
B
To
your
application
environment,
if
the
question
you're
trying
to
answer
is
truly
what
are
the
risks
of
my
application?
My
enterprise?
Those
risks
can
come
from
we're
not
on
a
variety
of
places.
They
can
come
from
the
code
of
thing
where
they
can
come
from
the
open
source,
libraries
or
components
or
frameworks
that
you're,
embedding
or
referencing
in
your
code.
They
can
come
from
the
way,
you're,
building
container
images
and
the
the
base
operating
systems
you're.
Using
for
those
images,
they
can
come
from
your
configurations
of
your
openshift
AWS
as
your
VMware
environments.
B
Then
I'm
going
to
take
a
couple
of
minutes
to
talk
about
that
as
well.
So
we
take
an
interesting
approach
to
analytics.
We
take
a
multi-tiered
approach.
Where
is
a
first
step?
We
collect
the
data
from
all
the
scanning
tools.
We
load
it
into
our
platform.
Then
we
start
analyzing
the
data
we
do
so
because
all
these
scanning
tools
provided
in
different
formats
and
different
levels
of
granularity
and
so
on.
So
we've
tried
to
normalize
it
and
and
look
at
it
on
the
same
basis.
B
We
then
help
you
better,
classify
the
data
and
overlay
your
own
perspective.
On
top
of
it,
you
can
specify
what's
important
to
you,
what's
not
important.
What
are
false,
known,
false
positives,
what
what
are
vulnerabilities
they
can
be
treated
with
higher
low
priority
that
indicated
by
the
various
scanning
tool,
vendors.
We
also
help
you
to
duplicate
data
within
a
single
scanning
tool.
B
In
this
case,
we
also
recognize
that
the
in
your
tool
chain,
you
may
have
overlapping
conflicts.
You
may
have
multiple
tools
to
detect
the
same
issue,
but
we
will
consolidate
the
data
and
create
composites
of
vulnerabilities
again
keeping
track
of
individual
sources,
but
we
reported
that
there
is
a
single
vulnerability
against
your
application.
Stack
notice
that
out
as
output
the
various
scanning
tools
beyond
that,
because
we
keep
track
of
your
entire
applications
that
here's
the
code,
here's
the
build.
There's
that
here
are
the
containers
that
are
being
created
as
part
of
this
uptick.
B
In
fact,
here
are
the
actual
deployed
components
the
web
server
the
database,
the
application
server
here
is
the
exposed
you
know
route,
here's
the
configuration
of
the
underlying
environment.
We
can
correlate
results
that
have
on
the
ability
I
discovered
across
that
entire
ecosystem.
We
can
correlate
findings
from
static
and
dynamic
issues
and
really
highlight
whether
any
of
that
statically
defined
issues
or
results
from
competition
analysis
are
exploitable
by
by
telling
you
that
there
was
that
an
actual
exploit
executed
against
that
finding
is
the
application.
B
So
those
are
our
real
issues,
regardless
of
the
severity
that
they
were
reported
with.
We
can
also
use
this
technique
to
tell
you,
what
are
the
likely
root
causes
of
the
exploits
are
being
observed
against
your
running
is
the
application.
Ultimately,
we
help.
You
understand
the
application
risk
by
keeping
your
risk
score,
that
we
calculate
based
on
a
number
of
different
factors.
Then
we
can
roll
that
up
into
the
application
groups
or
at
the
enterprise
level,
and-
and
we
can
give
you
an
indication
of
what
are
the
biggest
risk
areas.
B
A
C
Yeah,
so
I'm
gonna
introduce
briefly
introduce
a
big
platform
and
basically
showcase
how
the
things
that
Andy
was
talking
about
happening
from
a
user
perspective,
and
so
what
we
looking
at
in
this
screen
is,
first
of
all,
to
be
able
to
to
set
up
communication
with
a
specific
environment
with
their
code
repository
source
code
repositories,
things
like
openshift
cloud
environments.
We
need
an
integration
from
a
side
environment
which
is
basically
the
way
for
our
platform
to
know
the
way
like
within
this
specific
theme
right
and
in
this
case
in
case
of
openshift.
So.
C
C
Those
changes
back
to
Seibert,
so
sabot
can
Wycherley
those
results
against
what
was
there
before
and
take
any
actions.
So
if
you
deploy
a
new
application,
it
will
scan
with
appropriate
tools.
If
you
modify
the
existing
lines,
run
the
same
in
in
policy
again
and
whatever
happens
within
your
open
source
environment.
You
continues
to
get
in
the
picture
of
like
ever
evolving
security
vulnerabilities,
which
were
discovered
during
the
scanning
process.
C
So
basically,
once
you
create
this
information
from
a
side
back
platform,
we
run
this
car
within
this
environment,
and
what
you
can
see
here
is
the
applications
deployed
within
my
open
ship
tomorrow,
which
is
my
environment,
and
each
application
is
a
it's
basically
container
deployed
as
what
what
one
or
maybe
multiple
ports
within
a
specific
namespace
and
so
those
discovery
results
converted
to
things
we
call
targets.
So
these
are
individual.
C
Like
instances
of
what
exists
within
the
environment
could
be
repositories,
containers
hosts,
it
really
depends
on
a
specific
or
the
environment,
and
then,
as
an
RIA
was
talking
about,
we
have
a
many
integrations
with
would
exist
in
cameraphone,
open
source
security
providers.
So
we
able
to
run
big
variety
of
scans
and
this
number
of
deviations
is
ever-evolving.
C
So
you
can
go
against
your
repository,
so
you
can
run
static
code
analysis,
dynamic,
run
technologies
and
and
a
lot
of
different
things
and
within
each
product.
There
are
multiple
possible
to
achieve
these
multiple
configurations
like,
for
example,
for
M
map
network.
Regardless
you
can
just
do
network
mapping
or
you
can
do
more.
I,
provide
security,
vulnerability,
detections
and
stuff
like
that,
so
you
can
within
each
product.
C
You
also
have
like
wide
variety
of
typical
configurations
which
could
be
specific
to
your
environment
or
like
if
you're,
using
the
dynamic
application
tool,
you
can
basically
upload
the
entire
script
to
go
against
your
environment,
so
in
this
case
so
what's
happening
within
a
separate
platform.
We
create
this
mapping
of
integration
to
the
selected
scenarios,
which
you
would
like
to
apply
against
it
and
what
this
method
means.
It
means
every
time
there's
a
policy
group
for
openshift
intro
home
environment.
C
Basically,
so
this
mapping
had
creates
a
link
between
OpenShift
integration
and
a
map
and
map
scenario,
and
then
everything
where
it
is
exists
with
an
open
ship
environment
gets
camped
with
a
map
and
vulnerabilities
get
reported
to
Heydrich
and
with
that.
So,
with
the
application,
what
should
deployed
what
I
can
do
here
is
I
can
deploy
a
new
image
in
a
hybrid
test,
namespace,
which
is
my
entered
by
SAVAK
and,
in
this
case.
C
Allocation
and
what's
really
happening
under
the
hood,
is
a
what
should
get
notified
could
be
changes
within
the
environment.
Yep
runs
a
discovery
on
like
wouldn't
this
remark
within
this
environment
and
reports
results
that
decided
to
be
able
to
see.
What's
what
has
changed
if
everything
was
a
bit
modified,
removed
and
and
under
the
case
actually
triggers
internet
targets
which
exist
in
this
habit
platform
and
that
in
Jones
results
in
a
like.
C
Basically,
it
will
take
around
one
and
a
half
minutes
to
finish
and
once
it
finishes,
we'll
get
results
back
to
side
again,
you'll
be
able
to
see
it
on
individual
target.
Well
also,
you
can
see
example,
issues
which
were
reported
here
and
this
the
presentation
of
what
Andy
was
talking
about.
This
is
a
big
synthetic
issue
which
is
already
normalized.
B
What
would
what
we're
showing
here
is
that
we're
able
to
automatically
recognize
and
just
take
over
the
the
presentation
so
we're
able
to
automatically
recognize
that
a
new
application
was
deployed.
We
automatically
start
scanning
it
and
then
we
can
show
results
of
those
scans,
so
in
this
case
I
forget
which
one
exactly
we
were
looking
at,
but
but
this
is
an
example
of
an
application
that
has
one
policy
configure
against
it.
In
this
case,
it
was
able
to
find
a
critical
vulnerability.
B
You
can
see
the
details
of
the
vulnerability
as
well
as
as
all
the
specific
details
that
nmap
was
able
to
provide
in
this
case,
and
you
can
look
at
this
across
all
the
targets
and
as
you
build
application
entities
they
that
contain
multiple
targets.
You
can
see
an
aggregated
view,
you
can
see
correlations
and
you
can
see
additional
metrics
around
this.
A
B
B
Do
that's
effectively
a
thin
client,
that's
using
our
REST
API
is
that
has
access
to
the
customers
environment
so
so
through
that
age,
and
we
can
reach
both
the
internal
repositories
and
build
pipelines
as
well
as
the
internally
deployed
applications
open,
shipped
environments,
whatever
the
case
may
be,
and
then
we
can
also
perform
it
and
from
the
outside,
whether
they're
using
a
SAS
based
or
a
cloud
based
person,
control
repository
like
github
or
bitbucket,
or
whether
we
need
to
perform
dynamic
scans
of
their
external
endpoints.
So
we're
we're
basically
AWS
based
at
this
point,
I.
B
That's
right,
so
our
underlying
architecture
is
based
on
micro
services,
which
are
built
docker
containers
and
that's
deployed
in
in
kubernetes.
So
we
are
running,
you
know,
managed
kubernetes,
NE
ws.
Now
that
is
our
default,
offering.
We
also
offered
this
for
our
enterprise
customers
as
a
private
instance
of
the
platform
that
they
can
deploy
anywhere
kubernetes
or
opener
crimes,
so,
whether
it's
on
bare
metal
in
a
virtualized
environment
like
like
the
my
or
ESX,
or
whether
they're
running
in
a
cloud
in
managed
Fernandez
like
hash
or
AWS
or
or
Google
cloud,
really.
A
C
A
C
A
So
Andrea,
if
you
can
put
up
your
last
slide,
so
people
know
how
to
get
a
hold
of
you
guys.
Okay,
questions
that
would
be
great
and
I'm,
not
seeing
any
of
the
folks
who
are
listening
in
asking
any
questions.
So
you've
must
have
done
a
great
job,
doing
the
setup
and
the
demonstration.
So
that's
wonderful,
and
we
will
ask
that
you
send
me
the
slides
and
we'll
we'll
post
the
slides
and
the
video
shortly
up
on
YouTube
great.