►
From YouTube: Open Source Cloud Native Security with ThreatMapper
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
But
so
many
times
code
is
pushed
into
production,
but
in
some
way
it
can
degrade,
vulnerabilities
can
be
fined,
issues
can
happen
and
it
falls
to
the
application
security
team
responsible
for
those
production
platforms
and
the
applications
running
on
them
to
be
sure
is
that
application
still
secure
are
attacks
under
place.
Am
I
at
risk
shift
left?
We
liken
a
little
bit
to
the
story,
the
tragic
story
of
the
the
titanic.
A
We
know
the
tragic
story:
we
know
that
in
the
rush
across
the
atlantic
in
potentially
where
threats
were
not
seen
until
it
was
too
late.
The
tragedy
struck,
but
the
northern
irish
community
is
always
confident
to
say
she
was
fine
when
she
left
us,
don't
let
that
happen
to
your
applications,
just
because
they're
fine,
when
they
leave
development
and
move
into
production.
That
does
not
guarantee
that
there
are
no
weaknesses
in
your
attack.
Surface
and
threatmapper
exists
to
help.
A
Give
you
the
confidence
to
discover
what
is
running
within
your
production
platforms,
the
components
and
the
infrastructure
to
learn
the
topology
of
the
applications
that
have
been
deployed.
These
complex
multi-tiered
cloud
native
applications
and
from
that
tobology
then
to
deduce
the
attack
surface,
which
components
are
greatest
exposure
to
potentially
being
exploited
and
then
threatmapper
scans.
Those
components
running
in
production
against
up-to-date
vulnerability
lists.
A
It
begins
by
learning
the
attack
surface,
that
you're
exposing
in
your
applications,
whether
they're
running
in
public,
private
clouds
or
in
a
combination
of
both
investigating
that
environment,
interrogating
it
for
workloads
and
containers
and
looking
at
network
traffic
to
discover
the
topology
of
those
applications,
then
scanning
those
applications
pulling
manifests
and
matching
those
against
vulnerability
lists
compliance
technology
we'll
come
to
that
in
a
little
bit.
But
then
the
final
part
of
the
first
stage
of
threatmapper
is
to
put
this
information
together
to
build
a
threat
map.
A
A
The
shift
left
initiative
began
from
observations
from
ibm
and
the
like
that.
The
relative
top
cost
to
fix
bugs
and
remediate
issues
is
reduced.
The
earlier
on
within
the
software
development
life
cycle,
you
can
do
it,
but
the
net
result
is
that
shift
left
puts
a
huge
burden
on
the
side
of
developers
to
scan
their
code,
to
use
tools
to
ensure
that
the
code
that
they
are
building
is
100
secure
or
at
least
as
secure
as
is
physically
possible
to
make
it.
A
A
Is
that
environment
configured
correctly
increasingly,
that
problem
is
being
well
solved
by
cloud
providers
and
system
integrators
and
other
providers
who
are
ensuring
that
the
attack
surface
for
the
runtime
platform
is
limited
as
far
as
possible,
but
we're
still
left
with
a
problem
that
applications
that
left
development
in
a
secure
state.
Are
they
still
secure
when
they're
running
in
production?
Are
they
under
attack?
And
if
so,
how
should
you
respond?
A
They
are
real,
pertinent,
serious
problems
for
applications.
Today,
vulnerabilities
can
find
their
way
into
production
through
a
range
of
different
manner,
ways
or
rights.
It
takes
from
github
survey
of
their
own
code
bases.
It
takes
on
average,
four
years
for
a
vulnerability
to
be
discovered
in
code
that
has
been
published
to
github
and
once
discovered
it
takes
on
average
12
weeks
to
remediate
and
provide
a
fix
for
that
vulnerability
and,
as
a
result,
a
great
many
container
apps
contain
known
vulnerabilities
when
those
vulnerabilities
find
their
way
into
production.
A
The
web
server
could
access
on
the
local
file
system
an
unlimited
path,
traversal
exploit
in
the
cutting
edge.
Most
recent
releases
of
the
apache
web
server
problems
happen
in
production,
because
not
all
vulnerabilities
can
be
patched
before
code
is
deployed
to
production
increase.
So
often
it's
just
not
possible
to
track
down
and
patch
every
single
vulnerability
when
indeed
99
of
them
may
never
be
exploitable
anyway,
or
perhaps
your
production
environment
includes
third-party
resources.
A
Containers,
you've
pulled
off
docker,
hub
agents
from
monitoring
providers,
network
components
like
ingress
controllers,
that
you've
taken
from
a
third-party
source
and
those
sources
may
not
have
gone
through
the
same
rigorous
shift-left,
vulnerability
scanning
processes
that
you've
applied
to
your
own
code
but,
most
importantly
as
affected
equifax
and
the
users
of
the
apache
web
server.
Recently
unknown
vulnerabilities
can
be
discovered
after
a
component
has
been
deployed
into
production
shift.
Left
responsibility
ends
when
code
goes
into
production
and
we
need
a
way
to
pick
up
that
responsibility
and
apply
it
systematically
and
carefully.
In
production
environments.
A
Red
hat
surveyed,
a
large
number
of
openshift
users
over
the
last
12
months,
and
one
of
the
questions
I
asked
was
in
the
last
12
months.
What
security
incidents
or
issues
related
to
kubernetes
and
containers?
Have
you
experienced
94
of
their
respondents
said
they
had
at
least
one
security
incident
in
their
kubernetes
environment
over
the
last
12
months,
and
these
are
all
real-time
runtime
incidents,
they're,
not
things
that
could
have
been
caught
in
a
shift-left
project
securing
code
before
it
moves
into
production.
A
A
Development
and
devops
are
charged
with
innovating
as
quickly
as
possible,
building
new,
exciting
applications
and
features
getting
those
features
into
production
as
quickly
as
possible,
and
then
iterating
improving
those
rapidly
and
typically,
a
developer.
Devops
team
will
focus
on
a
small
set
of
applications.
A
They
operate
at
a
much
more
steady
pace
in
a
much
more
methodical
fashion,
threat,
hunting
looking
for
vulnerabilities
and
then
feeding
those
back
to
the
development
team
when
they
need
to
be
resolved,
and
it's
really
common.
Whenever
users
run
our
tools
in
their
production
environment
to
find
tens
of
thousands
of
potential
not
necessarily
exploitable,
but
potential
vulnerabilities
infrastructure-wide
for
host
hundreds
of
such
vulnerabilities
on
individual
hosts.
A
When
the
appsec
team
passes
this
information
back
to
the
development
team,
the
response
is
that
we
can't
we
cannot
prioritize.
We
cannot
act
on
this
enormous
list
of
theoretical
vulnerabilities.
Give
us
better
intelligence.
Tell
us
what
to
target
on,
and
frustration
comes
from
the
app
security
team
because
they
see
the
devops
team
as
just
not
putting
enough
priority
or
concern
towards
security
issues.
A
A
B
Thank
you
open
going
ahead
and
sharing
my
screen.
You
should
start
seeing
the
dashboard
of
threatmapper.
Thank
you
so
much
owen.
For
that
context.
The
truth
is,
there
is
a
semantic
gap
or
there
is
a
distance
between
what
happens
in
ci
cd,
which
is
where
you
scan
code
for
vulnerabilities
and
what
happens
at
runtime.
B
What
threatmapper
really
tries
to
do
is
use
the
runtime
context
to
prioritize
some
of
these
vulnerabilities.
Ideally,
this
shouldn't
be
about
only
vulnerability
management.
This
should
be
about
exploitability
management,
so
we
really
start
converging
going
from
those
thousands
of
vulnerabilities
to
those
handful
of
exploitabilities,
which
really
need
focused.
I
mean
just
imagine,
having
thousands
of
vulnerabilities
across
infrastructure
and
having
no
concrete
means
to
prioritize.
These
is
as
good
as
not
knowing
how
many
volumes
exist,
because
they're
not
actionable
they're
measurable
sure.
You
can't
really
act
upon
those.
That's
where
threatmapper
comes
in
picture.
B
What
you're,
seeing
here
really
is,
is
essentially
an
mri
scan
or
a
single
pane
of
glass
really
for
whole
of
your
cloudy
state,
and
this
is
basically
your
compute.
You
see
multiple
clouds
here,
there's
a
digital
ocean.
There
is
google
cloud
you
see,
third-party
apis
that
are
getting
called.
One
of
the
services
is
calling
slack
calling
into
slack
hook.
There
is
s3
bucket.
We
are
calling
into
here
from
one
of
the
one
of
the
cloud
nodes,
so
this
really
works
across
multiple
clouds.
Multiple
modalities
for,
in
this
particular
case,
you've
got
digitalocean.
B
You've
got
google
cloud,
let's
dig
deeper
and
see
what
we
have
running
here
and
how
threatmapper
sort
of
lets
you
scan
some
of
these
things.
Some
of
these
resources
for
vulnerabilities,
how
it
lets
you
prioritize
and
it's
you
know,
go
from
there
so
in
digital
ocean,
for
example,
here
you're
seeing
two
things:
one
is
a
region
nyc
one
and
the
kubernetes
cluster,
which
is
which,
which
could
be
across
multiple
regions
by
the
way,
so
they
are
being
shown
at
the
same
level.
Let's
dig
deeper
into
this
particular
zone
you're.
B
Seeing
a
couple
of
nodes
there
and
one
particular
vm,
which
seems
to
be
running
some
processes,
seems
to
be
running
some
parts
and
then
you're
going
to
be
able
to
start
seeing-
and
you
know
really
go
from
cloud
to
the
region-
to
users
all
the
way
down
to
processes
with
this
particular
view.
So
it
really
starts
with
visualizing
what
you're
running
within
a
cloud
or
across
multiple
clouds
within
your
containers
within
communities-
and
you
know,
even
you
know,
natively
running
processes
on
vms.
B
So,
for
example,
what
we
have
here
is
a
wordpress
pod,
and
this
is
how
it's
going
to
look
like.
So
we
have
come
all
the
way
down
from
digitalocean
this
hierarchy,
region
to
this
particular
node,
which
is
a
host
and
a
container
or
a
part
here
in
this
case,
which
is
wordpress,
and
then
this
is
really
the
first
view.
All
of
these
connections
that
you've
seen
these
are
live
every
three
seconds,
you're
going
to
start,
seeing
all
the
connections
that
are
happening.
B
We
really
start
building
this
connection
map
at
process
level
and
then
really
bubble
it
up
throughout
the
throughout
the
cloud
hierarchy
throughout
the
header.
Key
of
all
the
compute
and
resources
that
you
have
so
that's
the
first
part
now
coming
to
really
being
able
to
sort
of
act
upon
this.
You
know
visualize
resources.
B
You
can
scan
this
particular
container.
For
example,
this
is
wordpress.
You
can
say
you
know
what
I
want
to
scan
wordpress
container
for
all
the
vulnerabilities
you
could
say
I
want
to
scan
it
only
for
python
vulnerabilities
only
for
php
vulnerabilities-
or
you
could
say
you
know
what
scan
every
executable
piece
of
code
which
is
running
within
this
particular
part.
Within
this
particular
node.
You
could
even
go
beyond
and
say,
you
know,
scan
all
executable
code
within
this
particular
cluster
or
this
particular
region,
and
then
you
could
actually
do
this
at
runtime.
B
I
I
think
I
forgot
forgot
to
sort
of
speak
about
what
you
could
do
early
on,
for
example,
cicd
jenkins
base
scans
or
github
action
base.
Cam,
that's
the
first
part
that
you
can
do
with
threatmapper
sure
you
can
also
scan
your
vulnerabilities
within
registries,
for
example.
All
the
popular
registries
that
you
see,
including
cloud
registries,
are
already
connected.
You
can
use
you
can
use
the
threat
mapper
to
scan
that,
for
example,
we
have
a
docker
hub
register
here,
which
is
basically
showing
you
a
bunch
of
images.
B
You
can
scan
all
of
your
images
even
here,
but
this
applies
only
for
the
container
images.
Of
course
you
can
scan
them
one
by
one.
You
can
scan
them
in
in
a
batch
mode.
You
can
set
a
cron
job
from
the
gui
to
scan
them
periodically,
so
every
24
hours
you
can
have
all
of
these
standard,
so
that's
also
possible
so
cicdba
scanning
for
circleci
github
actions
for
jenkins.
You
know
all
of
these
popular
frameworks
that
you
have
is
available
registry
based
scanning.
B
You
can
do
from
here
as
well,
and
we
were
speaking
about
runtime
scanning,
which
is
essential
of
this
fit
where
you
can
say
that
here
scan
this
running
container
or
a
running
node
for
vulnerabilities,
and
this
is
where
it
sort
of
starts
becoming.
You
know
incredibly
cooler
really
because
we
start
using
this
runtime
context
to
really
tell
you
that
sure
you
stand
for
vulnerabilities
and
then
you
end
up
with
hundreds
of
vulnerabilities.
B
What's
the
point
of
it
all
right,
the
point
of
it
all
is
to
really
figure
out
what
are
those
top
one
or
two
or
three
or
four
vulnerabilities
which
have
a
direct
attack
path
to
those
vulnerabilities.
Okay,
that's
number
one
and
that
basically
makes
exploitability
now
this
can
be
exploited
at
that
particular
point
in
time
over
here.
What
we
are
really
seeing
is
this
container
has
been
scanned
before
you're,
seeing
there
are
a
whole
bunch
of
vulnerabilities
here,
many
of
them
are
just
low.
Some
of
them
are
critical.
B
There
is
one
critical,
but
here
is
an
attack
path.
What
is
being
shown
here?
We
are
showing
look.
This
particular
part.
A
group
of
parts
is
directly
accessible
from
the
internet,
so
anybody
could
just
scan
for
recon
essentially
do
a
record
and
if
they
have
a
payload
for
this
particular
vulnerability.
B
In
this
particular
case,
there
are
top
three
vulnerabilities,
which
seems
to
be
exploitable
over
the
network,
as
a
network
has
network
as
an
attack
vector,
have
a
fairly
high
cbs
score
and
you
know
which
port
they
are
sort
of
accessible
on.
You
have
all
of
this
detail
over
here.
This
is
where
the
runtime
context
comes
in
picture.
B
Let's
do
one
thing:
let's
dig
deeper
on
some
of
these
vulnerabilities
in
this
particular
view,
which
is
really
about
digging
deeper
on
all
of
these
vulnerabilities
and
adding
runtime
context
on
top
of
it
really,
for
example,
what
you're
seeing
here
is
two
tabs.
One
is
what
is
most
exploitable
at
this
very
instant
within
my
infrastructure
and
what
are
the
attack
parts?
How
can
the
bad
guys
get
to
those
vulnerabilities
show
me
where
to
go,
which
door
to
close,
which
you
know
container
to
patch
which
vm
to
patch?
B
All
of
that
really
that
comes
in
here
and
then,
of
course,
you
have
a
scan
by
scan
view
of
things
things
like
well,
I
scanned
this
for
a
one
container
yesterday
and
today
I
see
there
is
one
additional
vulnerability
and
then
you
can
really
go
down
and
see
what
really
might
have
caused
this.
You
know:
is
there
a
new
build
that
we
did?
Is
there?
Is
there
a
new
package
which
did
not
have
a
vulnerability,
but
it
is
reported
today
and
all
of
that
stuff.
B
Really,
let
me
dig
deeper
in
this
one
particular
vulnerability
and
see
how
this
really
looks
over
here.
What
you
have
is
this
is
a
gmp
2.6
2.1.
This
is
a
very
specific
version,
which
is
there
in
a
container
image
called
reverse
proxy,
which
seems
to
be
latest.
We
directly
pulled
it
from
docker
hub
and
then
this
is
the
container
image
id.
B
This
is
a
particular
layer
in
which
this
is
happening
and
the
score
is
five,
so
this
is
basically
a
medium
vulnerability
in
terms
of
you
know,
severity
and
then
you've
got
all
other
details
like
how
to
go
and
fix
it,
and
if
sometimes
our
information
is
not
possible.
So
we
just
point
you
to
you
know
the
appropriate
url.
Where
you
can,
you
can
go
and
see.
The
details.
B
Super
importantly
here
is
the
attack
vector
attack,
vector,
is
network
attack.
Complexity
is
low.
Authorization
is
not
required
in
all
of
these
details.
Now
these
details
have
a
meaning,
but
the
thing
is
these
are
computed
or
when
you
scan
statically,
you
do
not
have
the
runtime
context.
At
runtime,
when
you
say
attack
vector
is
network
and
attack.
Complexity
is
low.
You're
really
really
looking
at
a
tool
which
is
telling
you
things
like
this
hey.
This
is
directly
exposed
to
the
internet
and
look
at
this.
B
This
is
happening
on
port
number
8000
and
the
cvs
of
this
particular
cv.
It's
easily
exploitable
over
network.
You
must
go
and
fix
it.
Cbs's
tells
you
it's
five,
the
score
is
low,
but
this
one
is
loaded.
This
is
out
there
ready
to
be
exploited,
and
you
know
this
is
basically
the
prioritization
bit
which
you
can
do.
You
can
do
this
on
a
scan
by
scan
basis,
or
we
can
go
back
to
our
most
exploitable
vulnerabilities
now.
This
is
where
we
were
talking
about
the
runtime
context.
Some
of
this
context
is
just
not
there.
B
Who's
talking
to
that
container
is
that
container
doing
network.
I
o
you
know,
is
that
container
even
running
is
that
host
even
online.
All
of
this
data.
All
of
this
context
is
not
there
in
ci
cd,
it
is
also
not
available
when
you're
doing
snapshot
based
scanning
from
afar
or
some
of
the
network
scanner.
Some
of
these
details
are
just
not
there,
so
you
lack
this
context
to
really
prioritize
here.
B
B
We
have
web
dvd
container,
which
is
directly
exposed
to
the
internet
for
the
sake
of
testing,
of
course,
but
there
is
another
one
here
which
is
sitting
behind
a
proxy,
so
some
of
these
containers
or
some
of
these
nodes
might
be
sitting
behind
a
web
server
or
a
load
balancer
or
a
bunch
of
proxies
really
but
they're
still
equally
exploited.
It's
just
that
there
are
multiple
hops
to
get
there
with
this
attack
parts,
we
are
showing
you
what
is
directly
exploitable,
which
is
directly
talking
to
the
internet.
B
What
is
sitting
behind
a
proxy
or
a
bunch
of
proxies
doesn't
really
matter
as
long
as
the
vulnerability
is
there
and
can
be
accessed
remotely
it's
exploitable.
So
really
that
so
is
the
node
running.
When
was
it
patched?
Have
you
you
know,
installed
this
package
six
months
back
and
never
upgraded
it?
How
many
containers
or
how
many
instances
of
this
space
image
are
being
used
right?
Typically,
you
have
one
base
image
that
sort
of
is
used
as
a
base
for
everything
right.
B
The
same
thing
happens
for
amis
as
well,
so
if
it
is
in
one
of
the
base
images,
it's
probably
there
everywhere
and
it's
more
exploitable
and
then
again
the
runtime
context.
How
many
connections
are
there
are
these
connections
that
are
happening
on
the
on
the
same
port
where
this
particular
service
is
running,
and
this
service
is
the
one
which
is
actually
loaded
that
dependency.
You
know
going
forward,
you're
also
going
to
be
able
to
see
per
process
vulnerabilities
really
really
bringing
it
down
from
thousands
to
hundreds
understood.
B
You
know
dozens
and
then
down
to
that
one
vulnerability
or
exploitability
that
you
need
to
focus
on,
for
example,
here
what
you
have
here
is
this
particular
one
which
is
in
the
web
code
same
level
of
detail
again
directly
exposed
to
internet.
This
could
be
stashed
behind
or
hidden
behind,
multiple
layers
of
proxies.
B
You
would
still
see
this
as
the
first
vulnerability.
Why?
Because
the
the
vulnerability
is
network
exploitable
easy
to
exploit
all
the
details
are
here
and
we
are
actually
taking
the
runtime
connection,
data
and
really
overlaying
this.
This
cannot
go
wrong.
All
the
runtime
context
is
being
used
to
prioritize
the
exploitability
of
these
vulnerabilities.
B
So
that's
about
the
you
know,
most
exploitable
vulnerabilities
or
exploitability
management
and
the
top
attack
paths
that
you
need
to
focus
on
now.
Let's
move
on
to
some
of
the
integrations
that
we
have.
You
can
directly
file
a
jira
ticket
from
within
threatmapper.
B
So
you
can
say
you
know
what
here's
an
exploited
vulnerability
and
here
is
a
snapshot
of
connections.
Let's
go
and
fix
this
right
now
everything
else
can
be
right,
so
you
can
do
that.
You
can
file
a
jira
ticket
right
from
within
the
within
the
product.
You
can
get
notifications
from
slack.
Pagerduty
email
is
always
there.
You
can
have
custom
http
endpoints
configured
as
well.
Very
recently,
we
added
integration
for
chronicle.
B
If
you're
using
chronicle
your
sock
team
is
using
it,
it
can
even
ship
that
vulnerability
there
and,
of
course,
microsoft
teams
when
it
comes
to
sims
all
the
usual
integrations
we
have
here-
and
this
is
a
this
list-
is
ever
changing.
Really
we
already
integrated
with
splunk
elasticsearch,
which
is
basically
your
elf
base,
logging
stack,
which
which,
which
might
be
homegrown
sumo
logic.
We've
got
a
couple
more
coming
very
soon.
B
Jeera
we
spoke
about
you
can
archive
these
vulnerabilities
for
compliance
reasons
in
s3
buckets
as
well
right
for
up
to
six
months
or
longer,
as
compliance
is
managed,
you
can
you
can
archive
them
and
then,
of
course,
there
is
an
excellent
reporting
mechanism,
a
pdf
which
could
be
really
poor
could
be
per
you
know,
team
or
at
a
higher
level,
which
is
basically
an
executive
summary.
You
have
all
of
those
options
as
well.
So
once
again,
scanning
in
cicd
helps
you
measure
vulnerabilities,
helps
your
helps.
B
A
A
B
A
Traffic
that
sandeep
described
so
that
we
can
build
topology.
We
discover
the
vulnerabilities
by
scanning
the
hosts
and
the
containers
and
then
the
the
icing
on
the
cake,
the
ability
to
identify
the
most
exploitable
vulnerabilities
that
attack
path.
Visualization
gives
you
exactly
the
information
you
need
to
go
back
to
your
engineering
team
and
say
this
container,
this
virtual
workload
this
this
serverless
unit.
This
is
the
thing
that
you
need
to
fix.
A
A
Let
me
know:
go
on
and
we'll
talk
a
little
bit
about
the
roadmap.
So
if
I
can
grab
the
screen
share,
sandeep
yep.
A
So,
let's
talk
about
the
future
roadmap
for
threat
mapper.
What
you've
seen
is
production
ready
it's
used
by
a
number
of
our
users
and,
and
you
know,
and
other
users
across
the
world
to
secure
their
applications
right
now,
but
we
have
an
aggressive
roadmap
to
build
this
technology
out
to
build
a
true
broad
security,
observability
platform,
the
first
release
of
threat,
mapper
open
source,
was
made
a
little
over
a
month
ago
and
all
of
the
capabilities
that
sandeep
showed
you
in
the
demo
that's
just
passed.
A
A
These
are
effectively
runtime
tests,
shell
scripts
and
the
like
that
can
be
run
against
production
environments.
Looking
for
known
weaknesses
and
configuration
errors
from
the
base,
linux
image
up
through
to
kubernetes
master
configuration
or
node
configuration,
docker
configuration
or
individual
containers
based
on
the
wisdom
of
the
crowds
from
initiatives
from
organizations
such
as
cis
center
for
internet
security.
A
These
scat
profiles
and
similar
tests
apply
best
practice
tests
against
your
configuration,
and
this
is
something
that
you'll
see
coming
into
the
threatmap
or
open
source
platform
in
due
course.
So,
not
only
can
we
look
at
your
runtime
workloads,
we
can
also
look
at
and
test
the
underlying
platform
that
those
workloads
are
running
on.
A
A
A
Are
there
anomalies
in
resource
usage,
spikes
in
network
traffic,
spikes
in
application,
cpu
or
memory
usage?
Are
there
indicators
a
compromise,
so
has
a
workload
potentially
been
exploited
because
a
process
is
misbehaving?
It's
running
a
a
system,
call
it
shouldn't
like
a
tracing
operation,
it's
spawning
new
processes,
or
maybe
it's
crashing.
A
Have
there
been
unusual
activities
in
processes
acting
accessing
the
file
system.
Has
someone
find
a
way
to
create
an
executable
file
on
disk
and
then
start
that
file
running
very,
very
common
footprint
of
someone
who's
putting
in
place
something
like
a
bitcoin
miner
but,
most
importantly,
are
there
indicators
that
somebody
is
trying
to
attack
your
applications?
A
A
The
defense
technology
is
proxy
free.
It
operates
out
of
band
with
a
simple
kernel:
configuration
no
kernel
modules
required.
We
use
ebpf,
not
just
for
capturing
process
and
file
anomalies,
which
indicate
compromise,
but
also
for
capturing
network
traffic.
The
indicators
of
attack
and
our
intent
is
to
combine
this
technology
to
create
a
security
observability
platform
that
you
can
pull
information
from
in
real
time.
A
So
not
just
use
it
to
identify
on
vulnerabilities
that
need
to
be
closed
because
they
express
a
risk
to
your
applications,
but
also
to
identify
traffic.
That
is
indicating
an
attack.
May
be
in
place
on
our
ex.
Our
hope
and
expectation
is
that
organizations
will
be
able
to
build
ecosystem
solutions.
On
top
of
this,
whether
it's
a
simple
case
of
feeding
all
of
this
data
into
splunk
or
elk
for
your
own
analysis,
or
whether
it's
a
case
of
third-party
tools,
plugging
into
this
platform,
to
capture
the
information
that
we
can
provide
and
add
value.
A
But
let's
get
back
to
threatmapper
threatmapper
100,
open
source
available
on
github
apache,
licensed
very,
very
simple:
to
deploy
and
get
running.
The
first
step
is
to
get
threat.
Mapper
management
console
up
and
running.
It's
simply
a
case
of
grabbing
or
docker,
compose
spinning
that
up
and
you
can
have
threatmapper
running
on
a
single
docker-enabled
host
within
a
matter
of
minutes
and
then
you'll
wish
to
deploy
the
defense
sensors
across
your
runtime
environments.
A
A
Please
do
take
a
look.
We
would
love
to
get
your
feedback
get
in
touch
with
us
through
the
defense
community.
Slack
get
in
touch
with
us
through
github
feature
ideas
bugs
raise
an
issue.
Let
us
know
how
you're
using
threatmapper
start.
If
you
want
to
keep
on
track
with
what
we're
doing
with
threatmapper
over
the
next
few
months,
we
look
forward
to
catching
up
with
you
on
any
of
the
various
community
channels
that
are
available
to
support
threatmapper
users.
A
So
with
that
shift
left
secure
your
code
before
it
goes
into
production,
but
also
secure
right.
Do
it
properly
secure
your
own
production
environments
using
threatmapper
to
identify
vulnerabilities
in
production,
find
exploit
paths
and
then
seal
those
off
so
that
your
application,
your
users
and
your
data
are
secure.