►
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
Welcome
everyone
to
our
our
tech,
tuesday,
webinar
today
we're
going
to
be
talking
about
digital
transformation,
but
we're
going
to
take
a
slightly
different
perspective
on
things.
I
think
you'll
you'll
find
people
talk
a
lot
about
modernizing
your
apps
or
you
know.
A
In
more
recent
times,
it's
been
about
the
collaboration
and
maybe
the
the
enterprise,
but
we're
gonna
talk
about
appsec
and
and
why,
when
you're,
considering
going
through
a
digital
transformation
that
you
should
be
considering,
you
know
making
updates
to
your
application,
security,
sort
of
platform
or
or
strategy.
A
Just
to
introduce
ourselves
a
little
bit,
my
name
is
andrew
horgan,
I'm
a
technical
pmm
at
deep
factor.
I've
been
here,
for,
I
think,
almost
almost
six
months
now
surrounding
up
but
been
here
for
a
little
bit
learning
all
about
appsec
and
helping
kind
of
spread.
The
message
around
you
factor,
I'm
joined
today
by
karen
karen
I'll.
Let
you
introduce
yourself.
B
Hey
guys,
I'm
kiran
kamidi,
I'm
the
founder,
ceo
of
deep
factor,
addicted
entrepreneur,
lots
of
experience
in
the
cloud
native
and
other
areas.
I
was
at
cisco
before
and
the
bug
bit
me
and
I
started
another
company,
and
this
is
an
area
that
we
feel
is
going
through.
A
lot
of
change
as
organizations
are
creating
cloud-native,
containerized
applications,
kubernetes
applications
cetera
and
it's
important
to
identify
security
risks
in
these
applications.
You
know
during
the
course
of
development,
as
opposed
to
late
in
the
game
when
the
apps
get
rolled
out
into
production.
A
Absolutely
and
just
a
little
bit
about
deep
factor
we
were
founded
in
2019:
we've
got
people
from
all
over
the
sort
of
technical
sphere
from
you
know,
infrastructure
and
cloud
native
guys,
like
myself,
all
the
way
to
security
experts
from
you
know,
qualis
and
citrix,
et
cetera.
So
we've
got
a
good,
well-rounded
team
and
you
know
our
mission
ultimately
is
to
you
know,
help
developership,
secure
and
compliant
applications
right.
That's
that's!
That's!
If
we
can.
C
A
B
Yeah
I
mean,
as
as
many
of
you
guys,
probably
are
following
or
have
been
following
the
space
for
quite
a
bit,
which
is
probably
what
led
you
to
attend.
This
webinar
digital
transformation
is
has
been
happening
for
the
last.
You
know,
few
years
now,
ever
since
cloud
native
applications
started
becoming
the
way
you
build
modern
applications
that
has
that
has
resulted
in
there's
a
couple
of
we're
sitting
in
the
intersection
of
a
few
interesting
trends.
Number
one
is
every
organization
when
they're
building
new
applications
they're
looking
to
now
think
about.
B
Should
I
build
a
new
application
using
containers,
in
fact,
that's
kind
of
become
the
norm
for
any
kind
of
high
scale
application
with
kubernetes
or
containers
or
at
the
minimum.
Maybe
some
serverless
functions
being
thrown
in
there,
so
so
application
modernization.
If
you're
starting
application
building
from
scratch,
then
you
know
cloud
native
ising.
B
Your
application
seems
like
the
way
to
go
these
days,
but
if
you're,
a
larger
organization
that
already
has
a
bunch
of
applications
in
place-
and
you
want
to
try
to
you-
know-
transform
those
applications
and
modernize
those
applications
and
make
them
cloud-native.
Then
that's
another.
You
know
thread
of
initiatives
that
is
happening
in
in
pretty
much
every
large
company
that
we've
we've
been
talking
to
so
basically,
apps
are
getting
more
granular
they're
moving
at
a
faster
pace
because
you
want
to
ship
them
faster,
you're,
putting
them
through
your
devops
pipeline.
B
At
the
same
time,
the
number
of
security
related
breaches,
both
in
terms
of
the
size
of
breach
as
well
as
the
number
of
breaches
have
increased
quite
rapidly
over
the
last
few
years,
and
that
number
you
know
we
only
see
is
going
to
continue
to
grow
because
the
number
of
the
applications
are
increasing
quite
heavily.
B
So,
if
you
think
about
the
concerns
around
security,
I
mean
you
have
you
see,
stats
from
stack,
rocks,
adoption
survey
and
and
some
of
the
red
hat
state
of
kubernetes
security
reports.
B
They
indicate
you
know
that
pretty
much
every
kubernetes
deployment,
94
of
kubernetes,
you
know-
deployments-
have
experienced
security
incidents
and
or
they've
experienced
security
related
delays
where
issues
were
caught,
but
they
were
caught
late
in
the
game
which
resulted
in
releases
getting
delayed
because
somebody
had
to
come
back
and
the
engineering
team
had
to
context,
switch
and
fix
those
security
issues
etc.
B
Several
of
those
issues
are
observated,
but
there's
also
several
of
those
issues
that
are
application
or
development
related.
If
it's
an
ops
related
issue,
you
you
know,
the
fix
is
to
kind
of
protect
your
perimeter
or
you
know,
get
your
cloud
security
posture
configured
right,
but
if
it's
the
application,
then
the
best
way
is
to
make
sure
that
you
create
a
secure
application.
To
begin
with,
there
was
a.
I
was
just
attending
a
another
talk
lately
with
somebody
from
zscaler,
and
they
were.
B
They
basically
were
saying
you
know:
do
you
want
to
be
a
coconut
or
an
avocado?
You
know,
coconut
being
you
know,
secure
outside,
but
soft
inside
with
without
much
kind
of
security
inside
that's
important,
because
you
still
need
to
have
some
kind
of
parameter,
protection,
etc.
B
However,
it's
becoming
more
and
more
important
these
days
as
apps
become
you
know,
more
granular
and
there's
a
lot
more
eastward
traffic
to
be
for
your
application
for
your
organization
security
strategy
to
be
an
avocado,
which
is
you
know,
make
sure
that
your
application
is
secure
in
the
in
in
the
middle,
because,
once
your
app
is
secured,
then
then
the
rest
of
the
things
start
mattering
a
little
less
and
some
other
interesting
stats
here
is
in
terms
of
the
number
of
developers
versus
security
professionals
out
there.
So
the
number
today
is
26
million.
B
I
think
today
we
have
about
26
million
developers
and
that
number
is
supposed
to
get
to
45
million
by
2030
and
the
mind-blowing
stat.
That
I
heard
is
that
there's
going
to
be
500
million
cloud
native
applications
by
2023
and
come
to
think
of
it
cloud
native
and
kubernetes.
Just
got
started
five
six
years
ago.
So
this
is
like
a
a
massive
amount
of
growth
and
proliferation
in
terms
of
number
of
applications
being
designed
with
cloud
native
in
mind.
B
At
the
same
time,
if
you
look
at
the
number
of
security
related,
you
know,
people,
the
talent
pool
is
very
small
and
look
at
three
and
three
and
a
half
million
plus
unfulfilled
cyber
security
jobs.
So
it's
important
to
make
sure
that
you
automate
a
lot
of
these
cyber
security
functions
during
the
course
of
your
dev
or
ci
pipeline
or
in
production,
so
that
you
can
make
sure
that
you
create
secure
applications
to
begin
with.
B
So
what
is
driving
now
that
we've
taken
a
look
at
the
macro
landscape?
Let's
dig
a
little
bit
deeper.
What
is
driving
app
sec
modernization?
We
talked
about
app
modernization,
meaning
containers
and
kubernetes
and
serverless,
and
all
of
these
things
that
are
creating
that
are
enabling
people
to
create
secure
applications.
Now,
how
does
that
affect
application?
Security,
application
security
in
this
case
being
defined
as
the
ability
to
identify
all
of
your
security
and
compliance
risks?
B
During
the
course
of
your
development,
we've
talked
to
over
100
enterprises
over
the
course
of
the
last
year
year
and
a
half
and
we've
broken
it
down
into
five
themes
where
these
companies
kind
of
come
to
us
and
say
this
is
the
problem
we're
trying
to
solve
and
therefore
we
need
a
better
abstract
solution
number
one
of
that
is
app
modernization
where
somebody
is
creating
an
application
or
trans
transitioning
from
a
monolithic
application
into
kubernetes
or
some
kind
of
microservices
based
application,
and
they
want
an
appsec
platform
that
understands
kubernetes
that
is
designed
for
kubernetes.
B
You
know
I
don't
want
to
take
all
of
the
baggage
of
the
older
appsec
tooling
into
this
new
world,
because
I
had
put
together
a
hodgepodge
of
five
different
apps
tools.
As
part
of
you
know,
in
my
in
for
my
legacy
application,
I
don't
want
to
carry
the
same
things
forward.
I
you
know.
Is
there
a
cloud
native
application
cloud
native
centric
application
security
solution?
B
Number
two
is
devsecops
adoption.
I
want
to
make
sure
that
I
add
security
early
on
in
my
cicd
pipeline,
so
that
we
can
identify
the
risks
in
the
application
before
they're
widely
deployed
into
production
or
even
canary
rolled
out
into
your
into
a
smaller
group
into
your
production.
The
third
one
is
around
alert
fatigue
that
results
in
release
velocity
that
affects
release
velocity.
B
It's
my
current
abstech
tools
are
giving
me
too
many
alerts,
and
I
don't
know
which
ones
of
those
I
need
to
start
fixing
first,
because
of
that
either
we're
fixing
too
many
things
which
is
affecting
release
velocity
or
my
developers
are
just
losing
interest
in
work
or
with
confidence
in
that
tool.
The
fourth
one
we
see
is,
you
know.
I
have
tools,
tool
fatigue,
I
mean
there's
there's
just
too
many
tools
to
use
and
all
of
them
are
important,
because
security
at
the
end
of
the
day
is
a
layers
game.
B
B
And,
lastly,
is
there
I
you
know,
given
the
the
importance
of
of
observing
an
application
at
runtime,
especially
for
cloud
native
applications,
because
imagine
your
app,
which
was
basically
one
thing,
was
broken
down
into,
like
maybe
you
know,
10
plus
containers
now
and
all
of
these
micro
services
are
being
orchestrated
up
and
down
in
in
your
you
know,
kubernetes
or
other
environments,
and
you
need
visibility.
B
The
true
security
posture
and
risk
of
your
application
cannot
just
be
assessed
by
scanning
your
code
or
scanning
your.
You
know
artifact
of
containers,
but
you
have
to
actually
observe
what
your
application
is
doing
at
runtime,
because
maybe
it
has
some
it's
passing
some
clear
text
secrets
and
you
know
at
run
time
or
that
maybe
there's
an
environment
variable
that
has
a
key
in
it-
lots
of
interesting
things
that
show
up
only
at
runtime
that
you
cannot
just
get
by
looking
at
your
your
static
code
or
or
even
your
container
image
scanning.
B
So
these
are
the
five
reasons
why
people
reach
out
to
us
and
why
there's
a
need
to
rethink
appsec
and
create
a
next
generation
application
security
platform.
You
know
and-
and
that's
basically
the
course
of
this
discussion
today.
A
Yep
and
and
one
of
the
things
that
we
like
to
do
when
we
give
this
presentation,
is
kind
of
ask
the
audience.
You
know
where
or
you
know
what
are
the
driving
factors
for
them.
You
know,
obviously
I
think
for
each
of
you
there's
going
to
be
an
individual
reason
why
this
you
know
this
webinar
was
of
interest
to
you
and
so
we're
you
know
just
wanted
to
do
a
quick
poll.
A
I
think
virginia's
gonna
go
ahead
and
launch
that
in
the
background,
so
you
should
see
it
pop
up,
but
you
know,
let's
just
take
a
quick
second
to
answer
this
and
just
to
you
know,
understand
where
you
guys
are
coming
from.
Are
you
you
know,
like
karen
said,
are
you
looking
to
modernize
your
application
and
you
realize
you
know?
Maybe
this
is
the
right
opportunity
to
reevaluate
my
appsec
tooling.
Are
you
concerned
about
release
velocity
and
being
able
to
allow
developers
to
secure
more
quickly
but
also
ship
at
the
same
rate?
A
You
know
just
take
a
quick
second
to
off
to
to
make
a
selection.
I
believe
you
can
select
more
than
one.
So
I'm
just
curious
to
see
you
know
what
what
you
guys
are
saying
and
virginia.
I
know
you're
you're
on
mutant
off
camera,
but
I
think
you'll
see
the
results.
If
you
could,
maybe
you
know
let
one
of
us
know
where
what
seems
to
be
trending
more
popularly
than
the
the
others.
C
Yeah,
absolutely
so
as
of
right
now,
it
looks
like
seventy-five
percent
application,
modernization
with
a
second
runner-up,
being
unified,
appsec
great.
A
Thank
you
and
that
kind
of
drives
with.
I
think,
the
conversations
that
we
have
right.
It's
it's
you're
you're,
going
through
this
modernization,
you're
realizing
that
you're
kind
of
towing
all
this
stuff
behind
you
of
legacy,
maybe
more
traditional
ways
of
doing
appsec,
and
you
realize
this
is
an
opportunity
to
maybe
reevaluate
it
and
then
obviously,
while
you're
re-evaluating.
A
I
think
a
lot
of
vendors
in
this
space
have
have
kind
of
started
to
consolidate
and
unify
and
and
really
bring
together
a
lot
of
legacy
appsec
platforms,
so
you
can
kind
of
get
that
best
of
breed
approach
and
so
that
kind
of
jives.
I
don't
care
if
you
want
to
add
anything
else,
but
that
kind
of
makes
sense.
I
think,
from
our
perspective.
B
Yeah
it
totally
does
I
mean
people
are
frustrated
with
a
lot
of
tools
that
they
have
to
put
together
because
they
want
a
good
security,
comprehensive
coverage
at
the
same
time,
without
having
to
use
too
many
tools,
number
two
is
a
tool
that
understands
your
modern
application.
So
I
think
I'm
kind
of
pleased
to
see
that
both
those
are
the
two
number
one
number
two.
A
Exactly
exactly
so
before
we
get
into
you
know
the
next
generation
of
of
appsec
tools,
so
to
speak.
What
we
wanted
to
talk
about
a
little
bit
was
just
kind
of
defined
the
landscape
as
it
stands
today,
and
so
you
know
these
categories,
aren't
you
know
they're,
not
the
categories
right.
A
If
you
go
look
at
a
gartner,
mq,
they're
gonna,
maybe
kind
of
realign
it
a
little
bit
differently,
but
you
know
we
kind
of
wanted
to
paint
a
picture
of
the
current
abstract
landscape
and
how
we
view
you
know
where
these
tools
kind
of
fit
best
and-
and
this
is
kind
of
like
a
little
bit
of
a
101.
You
know
202
type
level
for
people
who
maybe
are
a
little
bit
new
to
app
stack
in
general.
A
So,
on
the
left
hand,
side,
you've
got
your
static
code
scanners,
so
these
are
things
that
are
going
to
be
looking
at
at
your
code
as
you're
writing
them.
You
know
one
of
the
more
recently
announced
sort
of
capabilities
is
infrastructure's
code.
The
rise
of
terraform
and
pollumi
have,
given
the
you
know,
a
rise
to
a
need
to
secure
your
infrastructure
code.
A
You
know
assass
the
static
application
security
tester
is
gonna,
be
looking
at
the
code
that
you
write
right,
so
you're
gonna
define
best
practices
for
your
developers
for
your
organization.
You're
gonna
ensure
that
code
is
written
to
the
the
sort
of
spec
and
and
quality
and
sort
of
framework
that
that
you
expect
within
your
organization
the
other
type
of
stack
code
or
static
scanners
that
we
have
out.
A
There
are
sca,
so
software
composition,
analysis
and
container
image
scanning,
so
an
sca
is
going
to
be
like,
like
a
sneak,
it's
going
to
be
observing
or
not
rather
nubs
or
being
scanning
your
container
images
in
your
artifact
repository.
This
is
something
that,
like
a
jfrog,
might
do
it
as
well,
and
it's
going
to
kind
of
help.
You
understand
all
the
potential
vulnerabilities
that
that
specific
image
might
be
susceptible
to
right.
So
it's
going
to
do
some
correlation.
Some
of
them
use
their
own.
A
You
know
their
own
databases,
some
of
them
use
like
the
the
publicly
availableness
cves
right,
but
the
idea
here
is
to
understand,
as
you
start,
to
pull
in
packages
and
dependencies
which
of
those
are
have
pre-existing
disclosed
c
of
cves
same
thing
with
container
image
scanning.
So
the
idea
here
is
that
we're
going
to
give
you
not
only
the
vulnerabilities
but
kind
of
a
readout
of
all
your
dependencies
and
all
the
different
packages
that
make
up
your
your
application
that
will
be
deployed
in
the
dynamic
category.
A
We've
got
dast,
so
das
is
dynamic.
Application
security
testing.
There's
a
couple
different
dash
das
tools
out
on
the
market.
You
know
we
at
d
factor
really
like
oh
zap,
but
the
idea
here
is
that
you
are
scanning
all
the
apis
for
your
application
and
you're
checking
things
like
the
oauth
top
10.,
so
cross-site,
scripting,
sql
injections,
buffer,
overloads
et
cetera.
Those
are
all
things
that
we're
going
to
be
scanning
with
using
a
dast
and
then
finally,
we've
got
the
runtime
category.
A
So
what
you
see
in
runtime
is
interactive
asts,
so
you'll
see.
I
ask
you'll,
hear
people
say
I
asked
a
lot.
This
is
a
fairly
older
I'll
say
within
the
last
two
decades
sort
of
technology.
It
uses
an
agent
most
most
commonly
to
observe
the
application,
as
it's
actually
running,
so
the
agents
generally
are
a
little
bit.
Some
developers
would
call
them
intrusive
because
you
do
have
to
actually
compile
them
into
your
code,
but
they
understand
the
language
intimately
right,
so
you
might
have
a
java
agent.
A
That's
gonna
actually
understand
all
the
different
calls
and
packages
loads
that
your
java
library
is
doing,
container,
skit
security
scanning
or
sorry
container
security
as
a
new
category.
That's
also
in
runtime
you'll
often
find
these
in
production,
so
you
can
think
of
like
an
aqua
or
a
twist
lock
right.
These
are
gonna,
be
side,
cars
that
sit
right
next
to
your
application
and
runtime
and
they're
going
to
be
observing
sort
of
the
network
traffic.
A
A
And
and
when
we
talk
to
customers
about
the
adoption
of
these
various
tools,
what
we
have
found
is
that
there's
four
very
clear
stages
when
it
comes
to
sort
of
devsecops
maturity.
So,
as
you
start
to
move
left,
as
you
start
to
shift
the
responsibility
of
security
from
the
appsec,
you
know
silo
the
apps
like
bu
with
your
organization,
and
you
start
to
move
it
onto
the
developers,
we're
finding
that
various
different
enterprises
are
in
different
stages.
So
the
first
app
sec
stage,
unfortunately,
is
actually
a
stage
we
have
had
conversations.
A
I
I
went
to.
I
went
to
lunch
with
a
non-profit
and
the
non-profit
doesn't
do
any
appsack
right,
so
they
just
release
their
code.
They
do
some
functionality
testing
and
they
release
it
into
the
wild
they're
very
early
stage.
They've
only
got
a
couple
of
employees,
so
they
don't
really
have
the
resources
or
the
bandwidth
to
do
appsec
right,
so
they
haven't
implemented
any
tools
more
often
than
not.
A
What
we
find
is
that
a
lot
of
customers
are
in
this
sort
of
like
reactive,
appsex
stage,
where
they
are
not
really
doing
anything
in
the
pipeline.
They're
not
really
securing
your
apps
there,
but
what
they
are
doing
is
once
you
know
the
app
goes
into
production,
maybe
once
every
month
or
once
every
quarter,
they
do
some
sort
of
a
pen
test
right.
They
they
contract
out
to
our
organization
that
specializes
in
an
app
sec
and
they
go
ahead
and
they
do
some.
You
know
some
testing
there
now.
A
Obviously
the
issue
here
is:
if
you
don't
catch
any
of
those
security.
Sort
of
you
know,
risks
in
the
application
until
you've
already
gone
to
prod.
Well,
so
can
the
bad
actors
right
the
bad
actors
have
an
opportunity
to
to
interface
with
your
app
just
as
much
as
the
pen.
A
Tester
does
the
other
stage
that
we
do
see
a
lot
of
the
larger
enterprises
for
sure
and
are
that
that
sort
of
proactive
appsec,
so
they
realize
that
you
can't
just
wait
once
a
quarter
to
go
ahead
and
do
you
know
a
pen
test,
but
what
you
can
do
is
every
time
I
build
an
image,
I'm
going
to
do
a
container
image
scan
every
single
time.
I
you
know,
maybe
once
a
quarter
once
a
month,
once
a
release,
I'm
going
to
do
a
desk
in
to
check
my
my
api
security
right.
A
A
I
might
have
like
a
container
security
product
in
play,
so
I
might
go
into
production
and
you
know
the
ops
team,
the
the
sres,
the
the
devops
team,
who
are
actually
in
charge
of
the
environment.
They
might
actually
be
doing
some
of
the
apsec
responsibilities,
but
you
know
not
it's
not
really
in
the
developer
world.
Yet
so
the
stage
three
is
kind
of
the
very
beginning
stage
where
you
think,
okay.
A
In
order
for
me
to
actually
mitigate
this
stuff
getting
further
into
the
pipeline,
why
don't
I
you
know,
have
my
developers
start
securing
and
observing
the
application
before
it
gets
put
into
production?
And
so
that's
what
we
call
call
cloud
native
apps.
The
idea
here
is
that
your
developers
are,
you
know,
as
they're
writing
their
code
or
doing
their
functionality.
A
You
know,
I'm
not
gonna,
advise
that
they
slowly
ramp
up
their
apps
capabilities.
I'm
gonna
say
like
no.
You
should
be
looking
at
tools.
They're
gonna,
get
you
immediately
from
stage
one
all
the
way
to
stage
four
right
without
having
to
go
through
those
sort
of
baby
steps
to
get
into
a
you
know
a
more
secure
posture.
A
So
with
that
being
said,
what
I
wanted
to
do
again
is
ask
a
second
poll
and
and
just
kind
of
get
a
feel
in
the
room
for
where
people
are
in
their
abstract
journey.
You
know
in
their
devsec
adoption
journey.
You
know,
are
you
someone
who
maybe
doesn't
take
apsec
very
seriously
today
or
are
you
doing
some
outband
tests?
Do
you
have
static
scanners?
A
Are
you
you
know
more
in
a
sage
three
sort
of
category
or
do
you
really
feel
like
you've
gone,
the
full
mile
and
you're
doing
cloud
native,
appsec
and
you've
you've
got
defsec
ops,
you
know
ready
to
go
so
we'll
take
a
couple
seconds
there
and
in
virginia
I'll
ask
you
to
speak
up
once
again.
Once
once
you
get
some
good
responses.
C
Sure
stage
one
is
definitely
in
the
lead
at
42,
but
stage
three
is
coming
up
as
a
close
second
runner-up,
so
yeah
stage,
one
and
stage
three
seem
to
be
the
most
popular
ones.
A
I
think
that's
I
mean
we've
done
this
a
couple
times.
I
I
really
feel
like
we
usually
get
stage
two
and
three
stage.
One
is
surprising.
I
I
want
to
say
shame,
but
that
would
be.
That
would
be
a
little
too
judgmental
for
this
audience,
but
so
thank
you.
Thank
you
virginia.
So
you
know
karen.
I
know
you
wanted
to
talk
a
little
bit
now
about
what
is
the
ideal
abstract
tool.
C
B
Cool,
so
you
know,
we've
established
the
fact
you
know
over
the
last.
You
know
20
minutes
of
this
conversation.
We've
we've
talked
about
the
need
for
cloud
native
applications
and
a
new
breed
of
appsec
tooling.
Now,
let's
talk
about
what
is
that
next
gen
appsec
tool
look
like
what
is
an
ideal,
next-gen
appsec
tool
and
I
think,
given
the
context
of
cloud-native
applications.
B
The
number
one
important
thing
is
that
this
appsec
tool
should
be
easy
to
insert
into
your
cloud-native
workloads,
and
it
should
observe
both
your
running
containers
as
well
as
your
static
container
artifacts.
So
a
cloud
native
first
application
security
tool
that
is
easy
to
drop
into
your
cube
environments
or
other
environments.
B
It
could
even
be
like
managed
kubernetes
like
it
could
be,
aws
fargate
or
even
your
your
own
rancher
clusters,
for
example,
or,
and
it
should
be
able
to
watch
both
the
static
aspect
of
your
container
images,
as
well
as
the
runtime
aspect
of
your
container,
which
is
very
easy.
Number
two
is
the
number
of
alerts
that
you
currently
see
with.
B
You
know
you
can
reduce
the
number
of
alerts,
because
you
only
focus
on
the
libraries
of
the
dependencies
that
have
been
loaded
and
used
by
your
application.
Therefore,
your
100
might
come
down
to
25..
The
other
thing
is
lack
of
runtime
visibility.
Today
is
a
problem
and
a
an
apsec
platform
that
that
understands
not
just
the
static
artifact
scanning
aspect
of
it,
but
also
runtime.
Like
I
talked
about
the
third
one
is
the
unified
part.
You
know
which
you
guys
chose
in
the
poll
is
one
of
the
problems
which
is
you
know.
B
This
one,
you
know
or
a
handful
of
appsec
tools
should
be
very
easy
to
kind
of
drop
into
my
environment,
and
it
should
get
the
various
security
insights
in
a
simple
pane
of
glass
or
integrated,
even
better,
as
part
of
my
ci
pipeline
like
if
I'm
using
jenkins,
you
know,
I
should
just
be
able
to
go,
you
know,
do
my
standard
bills
and
at
the
end
of
the
build
it
should
show
me
the
you
know,
all
of
the
things
that
matter
with
respect
to
bill
of
materials
and
the
changes
that
have
happened
across
releases
all
of
the
things
that
matter
with
respect
to
security,
posture
of
the
application,
both
static
and
runtime,
and
compliance
related
insights.
B
And
if
that
can
all
happen
as
part
of
my
ci
pipeline,
that
would
be
awesome.
So
that
would
be
in
you
know.
That
is
the
definition
of
what
a
next
generation
ideal,
abstract
tool
should
look
like,
and
there
is
an
important
aspect:
that
of
of
technology
that
has
emerged
over
the
last
few
years,
which
is
observability,
and
that
is
that
has
basically
enabled
us
to
observe
running
cloud
native
applications
very
deeply.
B
So
you
know:
there's
technologies
like
ebpf,
there's,
sidecar
technologies.
There's
also,
you
know,
library,
loading
technologies
that
allow
you
to
get
deep
visibility
into
your
application
behavior,
and
I
want
to
make
sure
that
we
spend
one
slide
talking
about
what
observability
is
and
how
it
has
evolved
and
why
it
is
relevant
to
appsec
and
why
it
is
important.
B
B
So
far,
all
of
these,
the
first
generation
of
observability
products
like
honeycomb
elastic
and
all
of
that
they've
focused
quite
a
bit
on
using
observability
for
logs
metrics
tracing
like
performance,
related
insights,
but
observability
is
just
beginning
to
be
used
now
to
get
application
security,
insights
and
you
know,
tools
like
aqua
or
cystic
or
deep
factor.
B
You
know
these
are.
These
are
some
of
the
companies
that
are
using
observability
to
observe
application
behavior
and
then
correlate
that
into
security
related
behavior.
So
what
what
is
it?
Why
is
it
important
for
appsec,
because
it
allows
you
to
watch
a
an
application
or
a
cloud-native
application
at
runtime
and
then
coordinate
or
correlate
the
behavior
of
the
application
with
what
is
acceptable?
What
is
not
like
a
simple
example
could
be
your
developer
brought
in
some
third-party
code.
B
They
did
not
know
that
the
third-party
code
was
making
an
outbound
connection
to
a
certain
geography
that
you
didn't
want.
But,
let's
just
for
example,
say:
let's
say:
antarctica
like
it
was
making
an
outbound
connection
to
antarctica
and
you
did
not
know,
and
they
did
not
know
either,
because
they
they
thought
it
was
a
a
third-party
component
that
was
already
that
didn't
show
any
cvs
in
the
scan
so
many
times,
runtime
behaviors
that
bypass
your
scan,
your
cve
list,
because
it's
just
you
know
the
it
was
known
vulnerability.
It's
just
bad
runtime
behavior.
B
Those
are
things
that
I
think
need
to
be
caught.
There's
several
examples
of
what
bad
runtime
behavior
could
be,
including
not
just
network
activity
that
I
just
gave
an
example
of,
but
it
could
be
files
that
are
being
touched
in
slash,
10
or
libraries
being
loaded
from
some
from
unwanted
folder
structures
in
your
in
your
operating
system,
so
on
and
so
forth.
B
B
B
A
lot
of
these
microservices
in
many
organizations
are
managed
by
different
teams,
so
they
may
have
different
base
up
base
operating
system
images.
One
could
be
using
alpine,
one
could
be
using
ubuntu
and
red
hat
and
so
on
and
so
forth.
The
not
only
the
base
images
but
the
languages
used
by
these
applications
for
these
each
of
these
microservices
might
be
different.
One
could
be
written
in
golang,
one
could
be
written
in
java
or
node.js.
B
So
there's
a
larger
surface
area
of
risk
and
and
therefore
you
need
to
make
sure
that
you
observe
each
of
these
running
containers,
while
they're
in
action,
as
opposed
to
just
scanning
your
container
image
when
it's
sitting
in
a
repo
repository.
So
just
the
you
know,
quick
scan
of
your
repos
is
insufficient.
B
You
need
to
make
sure
that
you
look
at
it
entering
time
so
now
that
we've
established
what
observability
is
and
why
it's
an
emerging
technology
trend,
let's
talk
about
what
observability
can
do
to
the
list
of
absence
findings
that
andrew
laid
out
before
so
this
was
a
slide
that
andrew
laid
out.
It
basically
says
these
are
the
tools
that
exist
in
the
market
today
and
there's
probably
one
tool
for
each
of
these.
You
know
boxes
that
you
might
be
using
in
your
organization
now.
B
The
question
is
obviously
we
don't
want
to
use
all
of
that.
We
want
to
make
sure
that
we
have
a
unified
view
and
what
is
it
that
unifies?
You
know
some
of
these
things.
It's
observability
is
a
fantastic
candidate
to
unify
that.
B
So
if
you
overlay
observability
on
top
of
these
tools,
whether
that's,
whether
you
use
multiple
tools
or
whether
you
use
one
tool
like
a
deep
factor
that
that
incorporates
observability
along
with
some
of
these
other
modules,
so
that
you
can
get
that
unified
experience,
it's
it's
a
way
to
augment
both
runtime
dynamic
and
static.
Finding,
so
here's
how
here's,
what
it
can
do
for
you
on
the
runtime
side.
Observability
will
give
you
visibility
into
your
application's
behavior
by
looking
inside
the
app
while
it
is
running.
There
are
several
ways
to
incorporate
observability.
B
If
you
use,
you
know,
tools
like
you
know,
sysdig,
it's
an
agent
that
you
put
on
the
host.
If
you
use
a
tool
like
aqua,
it's
a
sidecar
that
you
install
in
your
kubernetes
environment.
If
you
use
a
tool
like
deep
factor,
it's
a
library
that
you
drop
into
your
using
a
plug-in.
B
So
all
of
them
have
their
own
place
and
pluses
and
minuses
and
on
the
operator's
side,
tools
like
systig
and
aqua
are
probably
the
better
fit
if
you
are
using
production
rollouts
and
you
want
your
goal-
is
to
secure
your
production
environment,
but
on
the
development
side,
tools
like
deep
factory
are
the
better
fit
because
you
need
your
goal
is
to
identify
runtime
behavior,
that's
happening
in
every
thread:
every
process
every
container
in
every
pod
of
your
kubernetes
deployment,
for
example.
B
So
observability,
depending
on
how
it's
delivered,
can
give
you
great
visibility
into
runtime
of
the
application,
but
also
make
sure
that
you
pick
a
tool
that
that
condenses
all
of
these
insights
into
a
small
number
of
actionable
items,
as
opposed
to
just
overwhelming
you
with
a
ton
of
telemetry,
because
that's
not
what
you
you
know
what
what
you
want
in
is
you
don't
want
yet
another
tool
that
spits
out
a
ton
of
alerts?
B
You
want
a
tool
that
reduces
and
detects
anomalies
based
on
these
alerts
and
and
reduces
them
into
a
handful
of
actionable
items.
The
second
advantage
that
you
get
a
second
thing
that
that
a
good
observability
platform
can
do
for
you
is
to
augment
your
dust
a
lot
of
the
times.
Dast
is
kind
of
like
a
standalone
thing
that
you
run.
B
You
know
once
a
week
or
once
a
month,
or
sometimes
in
mostly
in
free
fraud,
sometimes
even
in
prague,
to
poke
the
application
from
the
outside
and
then
detect
vulnerabilities
like
the
os
top
10
type,
vulnerabilities
and
examples
of
das
tools
are
owasp
zap,
which
is
what
we
use
integrated
into
defactor,
but
we
also
see
a
lot
of
the
you
know:
burp
suite
and
acunetix,
and
neural
lesion
and
stackhawk,
and
all
of
these
companies
that
are
that
provide
das
tools,
the
beauty
of
combining
observability
with
dast.
B
In
fact,
I
just
gave
a
talk
on
friday
at
the
oas
owasp
conference
on
specifically,
that
topic
is:
how
do
you
enrich
your
tasks
by
combining
it
with
observability,
using
just
to
shorten
it
a
bit
the
by
by
using
the
ability
to
observe
an
app
from
the
inside?
You
actually
can
get
to
detect
things
like
hey.
My
app
was
listening
on
web
services
xyz,
and
you
can
use
that
information
to
pass
back
along
to
your
zap
scanner,
so
that
your
your
das
scanner
can
can
therefore
scan
these
new
interfaces.
B
You
can
also
identify
which
changes
have
happened
between
releases
so
that
you
know
your
das
scanner
is
not
now
going
and
scanning
every
endpoint
or
crawling
every
api
of
your
application
and
scanning
it
by
going
through
your
swagger
document,
it
only
scans
the
the
list
of
changes
which
reduces
the
scan
times
for
for
das,
which
is
one
of
the
biggest
pain
points
that
zap
scans
or
das
scans
in
general,
take
a
lot
of
time,
so
lots
of
benefits
by
combining
observability
with
a
dashed
product.
B
Again,
I
may
have
touched
upon
it
two
slides
ago,
which
is
the
ability
to
prioritize
your
insights
by
that
that
your
sca
tools
or
your
container
image
scanning
tools
provide
you
by
correlating
it
with
runtime
context,
is
something
that
observability
can
do
so
in
a
nutshell.
There
there's
so
many
different
tools
out
there,
a
good
way
to
think
about
it
is
unify
them,
but
you
can't
just
unification
is
not
just
throwing
all
these
tools
into
one
pane
of
glass.
B
It's
actually
combining
it
with
a
technology
such
as
observability,
to
give
you
deep
insights
and
help
you
augment
your
existing
tooling
and
reduce
the
the
number
of
things
that
your
developers
have
to
fix
at
the
end
of
the
day.
So
we've
talked
about
the
the
evolution
of
appsec
apps
and
into
cloud
data
world
cloud-native
workloads.
We
talked
about
the
that
resulting
in
a
the
need
for
a
modern
apps
like
platform,
but
let's
take
a
step
back
and
in
a
kind
of
un-vendor-related
way.
B
Talk
about
what
is
the
right
thing
to
do
when
you're
planning
for
your
absence
strategy.
So
let's
start
with
the
first
thing
that
you
know,
we
typically
recommend
you
know
any
organization
to
do.
That's
embarking
upon
this
journey
of
hey
I
want
to
put
apps
like
in
place,
is
understand.
Your
business
driver
you
know
is,
is
the
need
for
my
for
my
appsec
journey
digital
transformation.
Is
it
application
modernization
or
do
I
just
want
something
in
the
ci
pipeline,
or
am
I
just
trying
to
get
some
compliance
boxes
checked?
B
You
know
with
biden's
executive
order
around
bill
of
materials
as
well
and
so
forth.
Once
you
understand
that,
then
you
understand,
you
know
what
who
is
going
to
be
using
the
tool
I
mean:
do
we
have
resources,
a
dedicated,
appsec
team
that
is
going
to
be
doing
this
task,
in
which
case
they
will
be
doing
the
tool,
selection
and
embedding
into
the
ci
pipeline,
and
then
the
developers
are
going
to
be
consuming
it
or
do
I
does
it
have
to
be
done
as
part
of
the
engineering
organization?
If
so
identify
a
resource?
B
Some
you
know.
Essentially,
you
need
a
resource
to
put
the
tool
in
place.
You
need
a
process
and
a
resource
for
that
for
the
alerts
to
be
regularly
triaged,
because
without
an
understanding
of
the
proper
process,
that
program
is
going
to
not
be
successful.
So
you
want
to
make
sure
that
you
give
some
thought
to
it,
and
then
you
figure
out
what
you're
before
you
pick
the
right
tool.
You
know
understand
what
your
technology
requirements
are.
B
If
your
app
is
a
monolithic
application
that
is
written
in.net,
you
know
you
may
want
to
use
an
older
kind
of
is
tool
coupled
with
maybe
some
das,
and
maybe
some
code
scanners.
But
if
you're
building
a
modern
cloud
native
application
then
consider
a
cloud
native
application
security
tool.
If
you're
building
a
mobile
application,
then
you
need
some,
you
know
a
mobile.
B
You
know
security
tools
like
now
secure
and
stuff
like
that,
are
good
for
that,
and
once
you've
done
that,
then
you
understand,
you
know
what
budgets
and
timelines
you
know
make
sense
for
you.
The
beautiful
thing
about
picking
tools
that
offer
more
than
one
functionality
into
one
unified
experience
is
that
you
save
a
lot
on
money
as
well
as
the
time
it
takes
to
set
up
these
tools,
so
pay
attention
to
that
as
part
of
your
budget
and
then
make
sure
that
you
dedicate
a
certain
amount
of
time.
B
There
are
certain
tools
that
take
a
long
time
to
to
put
in
place.
It's
not
just
the
aspect
of
making
the
tool
and
it's
it's
the
aspect
of
getting
your
engineering
team
to
kind
of
work
with
your
security
person
or
the
appsec
team
to
get
the
the
triaging
process
kind
of
nailed
down
completely.
So
that
takes
a
little
bit
of
time
to
do.
Maybe
a
try
trial
run
with
a
couple
of
your
sprints,
and
then
you
know
get
that
incorporated
in
the
long
term
as
well.
A
Great
great
great
summary
there
karen
so
so
you
know,
just
as
we
go
ahead
and
close
out
this
webinar,
you
know
I
wanted
to
bring
you
guys
attention
to
some
resources
that
you
can
follow
up
with.
If
you
want
to
learn
a
little
bit
more
about
observability
and
dev
sex
devsecop
maturity,
we
do
have
a
couple
blogs
that
we've
written-
I
I
think
kieran
wrote,
maybe
both
of
these
actually
so
so
there
are
a
couple
of
good
blogs
about
what
does
observability
a
little
bit
more
on.
A
Why
it
matters
for
apsack
and
then
a
whole
another
blog
on
devsecops
maturity
and
what
sort
of
decision
points
and
sort
of
things
that
enterprises
need
to
consider
as
they
sort
of
make
their
way
through
that
devsecops
maturity.
You
know
staged
stepladder
that
we
talked
about
earlier.
A
We
also
you
know
if
you're
interested
in
learning
more
about
deep
factor,
we
do
have
some
some
case.
Studies
that
have
been
done
by
some
of
our
customers
so
feel
free
to
visit
our
youtube
page
and
watch
that
it's
pretty
pretty
helpful.
If
anything,
not
just
for
the
deep
factor
angle,
it's
it's
actually
kind
of
cool
to
see
peers
that
are
going
through
the
same
sort
of
challenges
that
you
might
be
going
through
and
and
their
thought
process
to
why
they
might
have
evaluated.
A
You
know
an
alternative,
abstract
tool
or
decided
to
do
something
versus
you
know
another
decision,
so
that's
always
a
great
video
to
watch
and
then.
Finally,
if
you
do
want
to
see
more
about
deep
factory-
and
you
would
like
to
see
a
demo,
please
feel
free
to
reach
out
to
us
and-
and
we
would
love
to
get
on
a
call
with
you
and
and
kind
of
walk
you
through
through
the
product.
So
you
know
unless,
unless
karen
you
have
anything
else
to
add
or
virginia,
we
missed
anything.
A
I
think
we're
we're
kind
of
at
the
top
of
the
hour
here
and
we
maybe
have
one
time
for
one
question
so
this
this
seems
like
a
good
one.
So
karen,
could
you
touch
a
little
bit
more
on
on
why
existing
app
sec
tools
might
not
work
for
a
cloud-native
development?
I
know
we
kind
of
talked
about
a
little
bit,
but
it
seems
there's
two
questions
in
here
that
seem
to
be
indicating
like
well.
I
have
all
these
tools,
I'm
confused.
You
know
why.
I
I
need
another
one.
B
Yeah
yeah.
No,
so
the
question
is
not
needing
another
one.
The
question
is,
as
you
move
from
your
traditional
applications
into
this
new
world
of
cloud
native
now
is,
actually
you
know
it's
it's
a
it's
a
problem
to
be
solved,
but
it's
actually
an
opportunity
to
kind
of
rethink
your
tool
set,
and
so
it's
a
good
time
for
you
to
reimagine
what
your
appsec
tool
set
should
look
like
for
this
new
world.
So,
instead
of
taking
you
have
two
choices,
I
mean
we
have
choice.
B
Number
one
is
to
take
the
existing
abstract
tools
that
we've
been
using
all
along.
It's
like
four
or
five
different
tools
and
put
them
all
in
this
new
world
or
choice.
Two
is
you
know,
re.
You
know,
leapfrog
it
and
go
pick
a
pick,
a
tool
that
understands
cloud
native
that
is
designed
to
understand
both
the
runtime
aspects
of
your
containers,
as
well
as
your
static
aspects
of
your
containers.
Therefore,
you
can
kill
two
boards
with
one
shot.
A
Yeah,
absolutely
you
know
that
that
was,
I
think,
that's
a
great
way
to
end.
I
think
that
was
ultimately
what
we
were
trying
to
advocate
for
when
we
started
this
presentation
an
hour
ago.
So,
thank
you
karen
for
your
time.
Thank
you
virginia
for
helping
facilitate
and
thank
you
to
all
of
you
for
tuning
in
and
listening
to
to
us
talk
a
little
bit
about
abstract
modernization.