►
Description
Observability has typically been used in the context of performance-related tracing and troubleshooting. Using observability for security and compliance, however, is a much more powerful, comprehensive, and modern way to think about your DevSecOps pipeline. This is done by observing the millions of events in every thread of every process of every container of an application and detecting security & compliance risks by identifying needles in this haystack. Observability and OWASP ZAP, by themselves, are highly valuable. However, together, 1 plus 1 is greater than 2.
A
A
We're
going
to
talk
about
what
wasp
zap
is,
and
it
seems
like
a
lot
of
the
folks
in
this
audience
might
already
know
it,
but
we're
going
to
do
a
quick
intro,
then
we're
going
to
get
into
one
of
the
some
of
the
latest.
You
know
the
challenges
in
in
in
the
absence
space,
given
the
the
latest
trends
around
cloud
native
application
development
and
what
is
causing
some
of
these
apps
challenges
and
driving
newer
ways
of
approaching
apsec.
A
We're
then
going
to
take
a
look
at
the
absec
tool
landscape
to
understand
the
types
of
tools,
at
least
at
a
high
level
that
are
available.
If
you
are
an
engineering
organization
or
a
software
development
shop,
that
is
trying
to
put
together
an
abstract
strategy
and
looking
to
understand
what
types
of
tools
do
you
use,
then
we're
going
to
go
through
overview
of
tools
that
are
available
at
your
disposal
disposal
today.
A
But
this
landscape
of
tool
is
now
drastically
changing
and
the
cutting
edge
next
gen
tech
is
observability.
We're
going
to
talk
about
what
is
observability.
Why
is
observability
important
in
the
absence
world
and
how
observability
is
changing
the
way
or
improving?
How
app
stick
is
going
to
be
done
and
specifically
double
click
on
dashboards,
specifically
looking
at
owasp,
zap
and
say:
why
can
os?
A
A
As
I
said,
my
name
is
kiran
kamiti,
I'm
the
founder
and
ceo
of
deep
factor.
What
is
deep
factor?
We
are
a
cloud
native
appsec
platform.
Our
goal
is
to
enable
developers
to
quickly
discover
and
resolve
security
issues.
Supply
chain
risks,
as
well
as
compliance
issues
during
the
course
of
development
that
includes
both
dev
test,
ci,
cd,
etc,
so
that
you
can
create
secure
applications
to
begin
with
and
therefore
reduce
the
number
of
vulnerabilities
that
exist.
When
you
go
to
production,
what
makes
deep
factory
unique
three
things
number
one.
We
are
a
unified
appsec
platform.
A
We
combine
a
the
various
pieces
of
insights
that
you
need
both
for
observing
your
cloud
native
applications
by
looking
at
static
container
images
such
as
container
scans,
independency
scans
builder
materials,
as
well
as
runtime
behavior.
Those
containers
when
these
containers
are
running
either
in
the
dev
environment
or
inside
your
kubernetes
environments,
so
providing
both
that
unified
view
of
static
artifacts,
as
well
as
runtime
container
images,
gives
you
a
comprehensive
visibility
to
your
application,
security
and
compliance
posture,
and
we
help
you
do
that
during
the
course
of
development.
A
As
you
look
to
create
secure,
cloud-native
applications
number
three
advantage
is
we
have
created
a
cloud
native,
specific
instrumentation
technology
that
is
super
cool.
It
is
a
language
agnostic,
library
that
is
purpose
built
for
cloud
native,
apps
or
kubernetes,
and
all
you
have
to
do
is
simply
drop
it
into
your
kube
cluster
as
a
web
hook,
admission
controller
or
simply
run
deep
factor
with
your
applications.
A
There's
zero
code
changes
to
your
application,
there's
absolutely
nothing
that
you
need
to
change
with
respect
to
your
deployment
mode
and
it'll
observe
it
inject
itself
into
every
thread
of
your
application
running
in
every
container,
while
the
application
is
running
in
your
test
or
ci
cd
environments
and
it'll
observe
every
thread.
Every
process
every
container
and
pod
and
it'll
give
you
condense
all
of
that
rich
telemetry
of
observability
findings
into
a
handful
of
actionable
meaningful
insights.
Therefore
creating
the
next
gen
of
application,
security
for
your
infrastructure.
A
A
The
goal
for
this
you
know
os
project
is
to
essentially
scan
your
application
by
passing
in
payloads
and
detecting,
based
on
your
application's
response,
whether
your
application
is
susceptible
to
any
of
the
os
top
10
issues
like
sql
injection,
cross-site,
scripting,
so
on
and
so
forth,
and
it
gives
you
all
of
these
findings.
It's
a
popular
tool.
A
It's
open
source,
it's
used
by
many
people
already
owasp
zap
by
itself
is
is,
is
one
of
the
the
useful
das
tools,
but
in
this
discussion,
by
no
means
are
we
restricting
when
we
say
observability
we're,
not
saying
deep
factor,
it
could
be
any
observability
tool
when
we
say
oh
wasp
zap
we're
using
that
as
an
example
of
a
das
product
it
you
could
be.
You
could
use
that,
for
you
could
apply
the
concepts
of
this
discussion
to
any
dashed
solution.
A
So
we're
going
to
talk
about
why
observability
and
dast
together
give
a
one
plus
one
is
greater
than
two
kind
of
experience
and
and
make
your
abstract
strategy
better
before
we
jump
into
the
specific
tooling.
Let's
take
a
look
at
what
is
triggering
some
of
the
changes
in
the
absolute
world
these
days.
What
is
causing
apsec
to
to
the
absence
of
yesterday,
to
no
longer
be
relevant
for
the
absence
of
tomorrow,
primarily
we're
seeing
a
lot
of
breaches,
we're
seeing
a
lot
in
terms
of
number
of
breaches.
A
We've
also
seen
over
the
last
couple
of
years,
the
size
of
breaches
has
increased
as
well
and
there's
plenty
of
references
on
the
bottom
that
that'll.
You
know
that
that
and
and
numerous
blogs
that
we've
written
as
well
as
plenty
in
online.
That
will
tell
you
what
has
changed,
why
that
is
that
is
happening.
A
A
However,
as
we're
building
a
lot
of
these
cloud
native
applications,
we're
also
seeing
a
lot
of
issues
with
both
how
your
infrastructure
for
these
applications
is
configured
such
as
you
know.
Your
kubernetes
configuration,
for
example,
as
well
as
how
these
apps
are
written
and
how
these
microservices
are
communicating
with
each
other,
there's,
definitely
a
gap
in
terms
of
the
security
issues
that
these
applications
are
exhibiting
and
those
that
are
being
caught
before
these
apps
to
be.
A
And
there's
a
lot
of
developers
that
are
writing
these
applications,
so
we
have
45
million
developers
supposed
to
have
we're
at
26
million
developers
today,
and
that
number
is
supposed
to
get
to
45
million
by
2030
and
with
the
500
million
cloud
native
applications
that
are
going
to
be
generated
by
these
developers
in
the
next
coming
years.
We're
really
producing
a
lot
of
apps.
A
At
the
same
time,
if
you
look
at
the
other
side,
the
number
of
cyber
security
staff
that
that
exists
today,
we
have
a
severe
shortage
of
the
number
of
engineers
that
are
cyber
security
engineers
that
are
appsec
engineers.
So
it's
important
for
us
to
automate
as
many
of
these
cybers.
You
know
absec
related
findings
in
your
application
during
the
course
of
development,
so
that
you
can
create
secure
and
compliant
applications
to
begin
with.
A
Number
two
is
devsecops
adoption.
This
whole
aspect
of
shift
left.
I
want
to
make
sure
that
I
bake
security
in
the
left
as
early
in
the
development
cycle
as
possible,
so
that
I
can
find
these
issues
and
essentially
create
secure
applications
to
begin
with,
the
third
trend
that
we're
seeing
is
alert
facility,
especially
with
some
of
the
legacy
apps
like
tooling.
We
are
seeing
that
you
know
if
you
scan
your
entire
container
imager.
If
you
scan
your
jar
file,
you
get
a
whole
bunch
of
dependencies
that
have
cvs
in
them.
A
That
list
is
too
long
and
you
don't
want
your
dev
teams
to
go
about
fixing
all
of
those
things
fixing
everything
is
not
the
point
creating
a
secure
application.
That
is
good
enough.
You
know,
for
most
practical
deployments
should
be
the
goal,
otherwise
you'll
never
reach
perfection.
So
how
can
you
make
sure
that
you
increase
your
release
velocity?
At
the
same
time,
you
address
the
important
issues
that
need
to
be
addressed
before
the
application
is
shipped
to
production.
A
The
the
fourth
trend
that
is
seeing
is
people
don't
want
to
use
so
many
different
tools.
There's
there's
plenty
of
tools
out
there.
You
know
some
tools
that
that
scam
codes,
some
tools
that
scan
container
images,
some
tools
that
do
the
scanning-
if
you
know
all
of
that
many
organizations
based
on
our
conversations,
seem
to
want
to
consolidate
it
and
there's
a
couple
different
ways
to
think
about
consolidation.
A
One
is
to
think
about
it
in
the
context
of
hey,
I'm
going
to
put
together
these
five
different
tools,
and
I
have
a
dedicated
you
know,
appsec
team
that
can
actually
manage
and
set
up
these
tools
and
operate
them
on
a
regular
basis.
It's
still
five
different
tools,
but
they're
coming
from
the
same
vendor.
So
that's
great.
That's
one
form
of
consolidation,
the
other
form
of
consolidation
which
we're
seeing
more,
is
unified
approaches
to
application
security.
A
The
fifth
one,
lastly,
is
runtime
observability,
which
has
currently
been
a
which
has
been
a
trend.
That
is
used
primarily
for
performance
related
findings.
You
know
logs
metrics,
trace
things
so
on
and
so
forth
is
now
being
used
in
the
world
of
application
security,
the
act
of
observing
a
running
application
or
running
container
and
identifying
which
functions
which
class
paths
are
being
called,
correlating
them
with
other
tools.
Like
software
composition,
analysis
tools
can
help.
You
reduce
findings.
A
Observing
running
applications
can
help
you
catch
things
that
your
sas
scanners,
for
example,
cannot
catch
such
as
maybe
sensitive
data
that
is
being
left
in
your
in
your
environment
variables
or
in
how
your
application
is
working
so
on
and
so
forth.
So
lots
of
interesting
findings
you
know,
can
be
obtained
by
looking
at
a
running
application.
A
These
are
the
top
five
trends
that
we
typically
see
and
we've
talked
to
over
100
organizations
in
the
last
year
and
a
half
or
so
you
know,
and-
and
we
can
bucket
the
concerns
that
these
organizations
have
in
around
absec
into
these
five.
You
know
verticals
now,
let's
jump
in
take
a
look
at
the
tools
that
are
available
at
your
disposal.
A
If
your
goal
is
to
set
up
an
a
proper
abstract
program,
in
many
cases,
your
organization
probably
has
some
or
more
than
some
of
these
tools
already
in
place,
but
a
simple
way
to
think
about
grouping.
These
tools
is
static,
dynamic
and
runtime.
The
static
tools
are
you're
scanning
your
static
artifacts,
whether
that's
your
code,
in
which
case,
in
which
case
it's
a
sas
tool
that
you're
using
static
application,
security,
testing
tool
or
you're,
probably
scanning
your
infrastructure
scope,
which
is
all
your
telephone
scripts
and
things
that
your
devops
team
has
written.
A
So
you
need
iac,
you
know
scanning
for
that.
The
other
static
artifact
that
you
typically
have
is
your
build
images
or
your
container
images.
So
if
you
want
to
scan
your
build
images,
you
know
you're
scanning
your
jar
files
or
your
npm
packages,
you're
trying
to
identify
cvs
that
exist
in
there.
That's
software
composition,
analysis.
If
you're
trying
to
scan
you
know
images
that
are
your
container
images,
then
you
use
something
like
a
j4
artifactory
or
things
like
that
to
to
scan
your
container
images
to
identify
vulnerabilities,
known
vulnerabilities
that
exist
there.
A
That's
your
container
in
the
scanning
tool.
The
middle
part
is
dynamic,
application
security
testing.
This
is
the
ability
to
actually
interact
with
your
application
by
sending
it
a
payload
receiving
a
response
and
then
based
on
that
telling
it
if
your
application
is
susceptible
to
certain
attacks.
Typically,
oh,
you
know
top
10
type
attacks
like
sql
injection,
for
example.
A
There's
the
difference
between
static
and
dynamic
is
that
static
is
purely
looking
at
your
static
code
or
build
artifacts.
Dynamic
is
actually
talking
to
your
application,
but
dynamics
still
does
not
know
what's
happening
inside
your
application,
still
talking
to
your
application,
as
if
your
application
were
a
black
box.
That
brings
us
to
the
third
the
right
side
of
this
diagram,
which
is
runtime
tools.
These
are
tools
that
actually
have
the
capability
to
watch
what's
happening
inside
your
application
processes,
it
started
with.
I
asked
interactive
application
security
testing
tools.
A
You
know
almost
a
decade
ago,
these
tools
started
emerging
and
these
tools,
you
know,
have
been
slowly
kind
of
making
their
way
into
becoming
the
mainstream.
However,
with
the
adoption
of
cloud
native
applications,
different
microservices,
the
service
area
of
applications
is
way
higher
than
ever
before.
Therefore,
it's
the
importance
of
observing
your
application.
Runtime
has
skyrocketed,
especially
now
that
you
have
a
lot
more
cloud
native
application,
security
testing
tools,
the
first
iteration
of
that
has
been
sidecar
type
approaches
or
agent-based
approaches.
A
An
agent-based
approach,
for
example,
sysdig,
is
something
that
you
install
on
your
host
machine
and
then
it
watches
all
of
the
the
kubernetes
hosts,
for
example,
on
which
your
application
is
running.
A
sidecar
based
approach
is
something
like
an
aqua
or
a
twist
lock
or
you
know,
prismacloud.
It's
now
part
of
palo
alto
networks.
So
these
tools
allow
you
to
watch,
watch
your
application's
behavior
by
being
a
sidecar
they're.
Looking
at
your
application,
still
not
from
not
quite
from
within
the
process
but
from
the
outside
observability
is
truly
changing.
A
You
know
the
game
there.
So,
let's
take
a
look
at
at
what
observability
is
observability.
Is
the
aspect
of
observing
your
running
applications
by
watching
everything
that
your
application
is
doing
from
within
the
process
like
you
could
applications
could
be
making
file
system
calls
or
process
calls
they
could
be
system
calls,
they
could
be
user
mode
calls.
They
could
be
touching
memory
and
or
accessing
certain
network
resources.
A
Observability
has
so
far
been
used
for
health
and
performance
reasons,
primarily
with
the
apm
tools
like
dynatrace
and
app
dynamics.
All
of
these
types
of
tools
you
know
beginning,
you
know
that
were
previously
monitoring
tools
now
beginning
to
become
more
observability
tools,
still
primarily
looking
at
performance,
but
nowadays
we're
seeing
increasing
use
of
observability
for
application
security,
the
ability
to
observe
an
application
and
understand
whether
what
the
application
is
doing
is
good
or
bad
from
an
application
security
standpoint.
A
And
if
there's,
if
your
application
is
doing
something
bad,
identifying
those
risks
and
sending
it
back
to
your
engineering
team
so
that
you
can
fix
those
those
things.
So
that
is
something
that
is
not
caught
by
static
code
scanners,
because
static
code
scanners
typically
are
looking
purely
at
your
code
or
built.
You
know,
as
software
composition,
tools
or
container
image
scanners
are
purely
looking
at
it
at
whether
there's
a
known
vulnerability
or
cve
that
exists
in
your
container
image.
They're,
not
really
looking
at
your
running
container
or
running
application.
A
A
Observability
can
not
only
help
you
identify
runtime
behaviors
in
your
code,
but
it
can
also
help
you
identify
runtime,
behaviors
in
open
source
or
third
party
code
that
your
developers
are
bringing
in.
So
let's
say
your
developer,
bring
in
brings
in
a
third-party
package
or
just
or
brings
in
an
npm,
and
it's
part
of
the
as
part
of
the
npm
package.
A
There's
some
other
third-party
packages
that
are
brought
in
and
those
things
at
runtime
are,
you
know,
maybe
reaching
out
to
random
locations
that
you
were
not
aware
of,
or
trying
to
touch
parts
of
the
file
system
that
you
don't
want
to
touch.
Those
are
all
runtime
behaviors
that
are
typically
not
captured
as
cds,
because
they
may
not
be
classified
as
a
as
a
common
vulnerability.
A
First,
you
can
use
cvss
course
that
still
is
not
sufficient,
because
it
will
still
probably
give
you
a
long
list
anyway.
A
good
way
to
prioritize
is
actually
observing
which
of
those
vulnerable
libraries
were
actually
loaded
and
used
by
your
application
and
using
a
good
observability
tool
can
tell
you
down
to
the
level
of
which
functions
or
class
paths
were
called
by
your
application.
Therefore,
you
can
correlate
that
finding
to
the
cds
that
were
found
and
say:
hey,
okay,
my
sca
tool
told
me
that
there
are
100
vulnerabilities.
A
You
know
80
of
them
were,
you
know,
cvs,
a
score
of
eight
or
greater,
therefore
they're
all
p1s,
but
then
my
observability
tool
is
telling
me
that
only
20
of
them
were
actually
used
by
my
application
at
runtime.
Great.
Let
me
start
by
fixing
those
first
now,
especially
with
cloud
native
applications.
Observability
has
become
a
must-have.
A
Why
is
that?
It's
because
your
cloud-native
applications
have
are
stretching
capabilities
in
multiple
directions:
number
one
they're
written
in
multiple
languages.
You
could
have
one
dev
team
that
is
creating
a
service
in
java,
another
dev
team
that
is
creating
a
service
in
golang,
another
dev
team.
That
is,
writing
in
node.js.
All
of
them
are
packages,
containers
and
then
you're
using
those
containers
as
part
of
your
overall
application.
A
Another
thing
that
is
that
we
typically
see
in
enterprises
that
are
building
cloud
native
applications
is
lack
of
standardization.
Around
container
based
images,
one
team
could
be
using
alpine,
another
team
could
be
using
ubuntu
or
you
know,
centos
or
something
you
for
your
base
image.
While
it's
good
to
standardize,
not
everybody
does
it.
A
A
Let's
go
back
to
the
diagram
where
we
were
talking
about
the
various
apps
tools
that
we
currently
have
at
our
disposal.
So
we
have
static
tools.
We
have
dynamic
tools
and
then
we
have
runtime
tools.
Now,
if
you
had
a
good
observability
platform
that
you
overlay
on
top
of
these
tools,
you
can
achieve
the
following
number
one.
A
On
the
right
hand,
side
you
can
actually
deliver
runtime
findings,
runtime
visibility
with
your
observability
tool,
so
the
right
side,
right,
side,
pillar-
that
you
know
that
was
previously
satisfied
by
I
asked
or
or
the
first
generation
container
security
tools.
Observability
tools
can
actually
address
that
that
entire
pillar-
so
that's
that's
great,
and
it
can
address
them
in
the
most
contemporary
cloud
native
friendly
manner.
If
you
pick
the
right
observability
tool,
the
other
thing
that
observability
tools
do
as
moving
a
little
bit
left
is
they
can
actually
help.
A
You
enrich
your
das
scan,
and
this
is
something
that
we're
going
to
go.
Double
click
on
in
the
next
couple
of
slides.
The
rest
of
this
discussion
is
observability
can
actually
make
your
dast
scanner
simpler,
faster.
It
can
also
make
you
more
comprehensively
scan
the
various
parts
of
your
application.
A
The
now
going
back
to
the
left
side
of
this
diagram
is
observability.
Tools
can
also
complement
your
static
scanner
tools.
For
example,
if
you
had
a
container
image
scanning
tool
or
a
software
composition,
analysis
tool
that
gave
you
a
list
of
vulnerabilities
observability
tool
can
tell
you
which
of
those
vulnerable
functions
were
actually
used
by
your
application.
When
your
app
was
running,
like
I
said
down
to
the
function
or
class
path
level,
therefore,
you
can
use
that
information
to
prioritize
which
alerts
to
actually
attend
to
first.
A
This
is
a
great
way
for
you
to
reduce
the
alert
fatigue
that
has
been
plaguing
this
whole
apsec
world
and
in
fact,
many
apps,
like
many
engineering
teams,
have
stopped
using
products
because
they
spin
out
too
many
alerts,
so
using
observability
is
a
great
way
to
not
only
get
you
the
runtime
findings,
but
also
make
your
das
better
and
also
make
your
software
composition
and
continuum
and
scanning
alert
volume
lessen.
So
that,
in
a
nutshell,
is
the
benefit
of
you
know
overlaying
observability.
A
Let's
get
into
now.
Double
click
on
on
this
on
the
middle
part
of
this.
This
diagram,
which
is
how
can
observe,
dashed
together,
give
a
one
plus
one
greater
than
two
kind
of
result
for
this.
First,
let's
take
a
look
at
a
dashed
product
in
this
case
we're
talking
about
wasp
zap,
but
the
same
concept
can
be
extended
to
other
das
tools
as
well
without
observability,
just
a
regular
das
product.
How
does
it
work
and
what
are
some
of
the
challenges
that
we
see
today?
A
Here's
an
example
and
I'm
taking
an
example
of
a
cloud
native
application,
because
that's
really
the
whole
focus
of
this
discussion
in
the
context
of
cloud
native
world.
So
here
you're
seeing
the
kubernetes
cluster,
the
cluster
has
a
bunch
of
pods.
Each
pod
has
a
few
containers
that
come
up
and
go,
and
in
here
in
this
case
we
picked
an
application
that
has
a
few
services
and
you
have
a
front-end
one
service.
You
have
another
front-end
service,
you
have
my
app
and
then
you
have
back-end
kind
of
service.
A
Now,
challenge
number
one
with
with
zap
is:
let's
say
you
have
zap
scanner,
your
your
it
team
or
your
devops
team
has
gone
through
the
effort
of
setting
up
a
zap
server.
The
zap
server
is
now
set
up,
which
itself
is
work
and
then
once
you've
set
it
up,
you
know
you
can
you
can
now
scan
your
cloud
native
application?
A
The
problem
number
one
in
this
case
is
your
container's.
Ip
keeps
changing
because
containers
are
feminine.
You
know
many
times
the
ip
of
the
container,
the
service
that
needs
to
be
scanned
by
zap
changes.
So
how
do
you
ensure
that
you
can
keep
scanning
it?
You
know
across
various
versions
of
your
application,
especially
as
you
incorporate
this
setup
during
your
ci
pipeline.
A
The
second
problem
is
coverage.
Gap
dashed
scans.
Have
there's
a
couple
of
different
types
of
dash
cams?
You
can
either
crawl
the
web
interfaces
that
the
application
is
exposing
and
therefore
do
a
spider
crawl
of
the
web
interface
or
you
can
pass
in
a
swagger
dock
to
the
application
to
your
scanner
so
that
you
can
scan
the
apis
that
were
documented
in
the
swagger
dock.
A
But
it's
very
common,
as
many
of
you
know
that
the
swagger
dock
is
not
up
to
date,
so
there
are
any
apis
that
are
probably
not
even
documented
in
the
swagger
dock,
or
maybe
there
are
some
apis
that
are
documented,
but
but
they're,
probably
out
of
date.
So
how
do
you
make
sure
that
you
scan
undocumented
apis
as
they
keep
changing
as
your
application
developers
keep
adding
more
code
apis?
How
do
you
make
sure
that
you're
on
top
of
it
without
having
to
rely
on
just
the
swagger
document?
A
A
Different
versions
of
the
applications
you
end
up
scanning
the
whole
application
anyway,
and
that
results
in
the
same
kind
of
time
across
the
different
versions
of
the
application,
but
many
times
between
release
one
and
release
two
or
between
a
sub
release.
One
yesterday's
you
know
build
and
today's
build,
you
probably
don't
need
to
scan
the
entire
application
anyway.
A
Therefore,
what,
if
you
know
you
could
identify
just
the
deltas
and
scan
those
deltas
to
make
your
scan
times?
You
know
faster.
In
that
case,
you
could
actually
use
your
dash
scan
on
a
regular
basis,
part
of
the
ci
cd,
as
opposed
to
using
it
once
a
month
or
once
a
couple
of
weeks
or,
however,
frequently
you
set
it
up.
A
You
know
with
this
limitation.
So
to
summarize
these
problems
that
we
have
today
with
das
tools,
number
one
there's
setup
overhead,
especially
with
cloud
native
applications.
The
ips
keep
changing.
So
you
need
a
devops
resource
to
kind
of
manage
that
infrastructure
and
make
sure
that
you're
constantly
on
top
of
that
application
set
number
two.
There
are
coverage
gaps
if
you
don't
have
documented
apis.
A
If
your
dev
team
is
not
staying
on
top
of
you
know,
updating
your
swagger
document
all
the
time,
it's
really
hard
for
you
to
stay
on
top
of
it
number
three
is
your
scans
are
very
slow
and
which
is
why
many
people
delegate
desk
cans
to
the
once
a
you
know.
Month
kind
of
you
know
scan
as
opposed
to
doing
it
regularly
as
part
of
your
ci
cd.
Now,
let's
take
a
look
at
how
we
can
improve
and
solve
these
challenges
by
combining
observability
with
your
with
your
das
scanner.
A
How
your
os
zap
setup
this
for
the
same
application
would
work
if
you
pick
the
right,
observability
solution
and
later
overlaid
that,
on
top
of
your
zap,
what
exactly
can
observability
do
with
zap?
The
main
thing
here
is
because
observability
is
watching
your
application
from
the
inside
with
observability.
A
You
can
actually
get
a
feedback
loop
established,
so
if
you
can
watch
your
service
or
microservices
or
application
from
the
inside
and
pass
that
finding
some
of
the
information
back
to
your
zap
scanner
have
that
feedback
loop
to
your
zap
scanner
or
any
dash
scanner
and
tell
the
zap
scanner
what
you're
seeing
inside
your
application,
then
you
can
actually
do
some
brilliant
things
in
this
case.
Let's
go
back
to
these
three
challenges
and
see
how
we
can
solve
these
three
challenges.
A
Now
that
we
have
something
that
is
observing
your
microservices
from
the
inside
the
moment
and
ip
changes,
you
can
actually
send
that
change
information
back
to
the
zap
scanner,
so
zaps
can't
exactly
know
which
ip
to
scanner.
That
simplifies
the
need
to
have
a
load,
balancer
and
other
things.
So
you
don't
have
to
involve
90
percent
if,
if
the
observability
tool
communicated
with
with
the
the
zap
scanner,
that
is,
that
is
brilliant.
So
it
helps
you
completely
eliminate
or
drastically
reduce
the
amount
of
devops
teams.
A
Work
involved
in
setting
up
this
infrastructure
because
your
observability
tool
is
automatically
keeping
your
dash
scanner
updated
on
changes
of
ip
number.
Two
is
comprehensive
coverage
around
around
your
ip
changes,
because
you're
now
observing
your
application
from
the
inside.
You
know
which
web
services
are
being
started.
A
You
know
which
uris
you
know
that
are
even
if
it's
undocumented
your
app
might
be
using
so
on
and
so
forth,
but
because
you're
constantly
observing
your
application
and
therefore,
using
that
information
you
can,
you
can
tell
the
zap
scanner
to
scan
those
those
uris
that
the
observability
tool
has
observed
from
the
inside.
Therefore,
even
if
a
certain
api
is
not
documented,
you
get
that
comprehensive
coverage,
and
even
if
your
engineering
team
is
constantly
making
updates
to
your
application
anytime,
a
new
uri
is
introduced
or
anytime.
A
A
The
third
problem
we
talked
about
was
scan
times
now
that
you're
actually
observing
what's
happening
inside
your
application.
If
there's
any
changes
to
the
application,
the
website
introduced
between
release
a
and
release
b,
then
the
observability
tool
can
actually
tell
the
zap
scanner
to
only
scan
those
changes.
That
way,
you
can
program
your
das
scanner
to
scan
the
deltas,
and
once
you
only
scan
the
deltas,
your
scan
times
are
going
to
drastically
speed
up.
A
A
So
that,
in
a
nutshell,
is
why
observability
can
make
your
zap
scan
better
observability
by
itself
finds
only
inside
the
app
behavior
das
scan
by
itself
can
only
scan
the
application
by
from
the
outside,
but
by
building
a
platform
that
allows
your
observability
tool
to
talk
to
your
zap
scanner.
You
can
actually
make
your
data
scanner
a
lot
more
powerful
and
therefore,
at
this
you
know,
and
all
of
these,
while,
while
your
dash
scanner's
gotten
a
lot
more
powerful
observability,
all
the
time
has
been
watching
your
inside
the
application
behavior
as
well.
A
Therefore,
you
get
one
plus
one
is
greater
than
two
kind
of
behavior
at
the
end
of
the
day,
so
we've
talked
about
various
appsec
tools
that
are
out
there,
especially
as
you're
building
your
cloud
native
application.
Why
adding
observability
to
the
linux
is
a
great
way
and
there
are
tools
out
there
that
are
just
standalone
observability
tools.
There
are
tools
out
there
that
do
observability
together
with
built-in
scanners
and
and
software
compensation
tools,
so
that
you,
you
have
that
unified
kind
of
experience
use
the
right
tool
for
your
application.
A
Your
company,
let
me
give
you
a
quick
kind
of
you
know
this
slide
we're
going
to
quickly
touch
upon
if
you
are
planning,
if
you're
building
a
cloud
native
application,
you're
thinking
about
hey
what
is
the
right
way
to
kind
of
think
about
my
abstract
strategy.
This
slide
is
a
good
kind
of
framework
for
you
to
think
about
it,
because
every
organization,
the
the
way
you
need
to
solve
the
problem,
is
different
from
how
other
organizations
do
it.
So
you
need
to
think
about.
First
of
all,
what
is
your
business
driver?
A
Is
it
digital
transformation
is
the
primary
reason
that
I
need
to
rethink
my
app
stick
because
I'm
starting
I'm
creating
cloud
native
application,
and
I
don't
want
to
take
the
legacy
appsec
tools
and
again
take
them
to
this
new
cloud
native
world.
I
wanted
to
think
how
I
do
that
for
the
new
world,
or
is
it
because
I
want
shift
left?
You
know
I
just
want
cicd,
it's
not
the
app
modernization
that
is
driving
my
appsec
modernization.
It's
really
that
I
just
want
to
add
security
findings.
A
You
know
ahead
to
the
left
during
the
course
of
my
development,
or
is
the
primary
driver
for
you,
your
bill
of
materials,
maybe
joe
biden's
executive
order.
That
basically
says
you
need
to
have
access
to.
You
need
to
have
visibility
into
your
application.
Software
bill
of
materials
you
know,
is
that
the
driver
or
compliance
depe.
I
try
to
identify
what
your
main
driver
is
and
then
because
that'll
set
the
res
the
tone
for
the
rest
of
your
your
strategy.
A
A
In
some
cases,
it's
the
engineering
leadership
that
does
the
triages
and
fixing,
because
their
goal
is
to
make
sure
that
by
the
time
the
app
goes
to
the
appsec
team
they
create
a
secure
application,
delivers
a
reasonably
secure
application
for
the
appsec
team,
so
that
the
things
that
the
appstick
team
will
later
find
is
lesser.
But
in
some
cases
it's
the
appsec
team.
That
proactively
wants
to
make
sure
that
engineering
team
incorporates
these
tools
in
the
ci
pipeline
so
that
they
can,
you
know,
end
up
overall
producing
a
better
quality
application.
A
So
it
really
depends
on
on
the
team.
So
I
think
understanding
that
persona
a
little
bit
is
going
to
be
very
useful
as
well.
The
third
important
thing
is:
what
are
your
technology
requirements?
Are
you
creating
a
cloud
application,
a
back-end
application?
You
know
which
is
cloud
native
and
you
want
to
use
a
cloud
native
appsec
tool.
Are
you
creating
a
mobile
application
or
you
know
on
your
ios
or
android,
with
not
much
of
back-end
components?
A
And
you
want
us,
you
want
to
find
security
some
of
those
tools
or
are
you
using
a
monolithic
kind
of
legacy?
Application
still,
you
know
that
is
written
in
dotnet.
You
know,
depending
on
where
you
are
your
the
tool
set,
that
you
use
the
vendor
choices
that
you
make
etc
is
going
to
be
very
different
and
in
some
cases
observability
makes
sense.
A
You
know
for
a
small
team
size
if
you're
a
larger
organization
or
an
enterprise
that
wants
to
make
sure
that
you
have
the
ferrari
with
everything
you
know
you
want
the
best
software
composition
tool.
You
want
the
best
observability
tool,
you
want
the
best
container
scanning
tools
and
you
have
the
budget
to
do
it
and
you
have
the
appstick
team
and
the
timeline
that
allows
you
to
kind
of
manage
all
of
these
best-of-breed
tools.
A
Then
sure
that's
a
that's
a
different
ballgame,
you
you,
you
want
to
make
sure
that
you
pick
you
look
for
the
best
in
everything
unified
in
that
case
becomes
less
important,
but
the
the
best
of
each
becomes
very
important.
So
understanding
of
your
business
drivers,
your
personas
technology
requirements
and
then
your
budget
timeline
is
kind
of
how
we
typically
recommend
our
customers
kind
of
go
about
thinking
about
their
apsec,
depending
on
that
your
technology
and
tool
choices
and
your
process
choices
are
going
to
be
different.
A
A
How
specifically
observability,
can
make
your
not
only
give
your
runtime
insights
but
make
your
existing
other
apps
like
tooling,
better
such
as
your
dash
or
or
your
software
composition
tools.
We
did
a
slightly
of
a
deep
dive
on
how
observability
and
dust
are
made
for
each
other
and,
if
you'd
like
to
know
more
there's
plenty
of
other
resources
in
our
blogs
page,
there's
other
webinars
that
we
have
as
well.