►
From YouTube: Secure: Composition Analysis Lunch n Learn - What are the different Application Security Tests (AST)
Description
00:18 AST market
02:50 SAST, spell checker, identify by patterns
04:13 secret detection, API keys
04:46 DAST, deployed code
06:37 dependency scanning
08:04 container scanning
09:15 licence compliance
09:47 Fuzzing , business logic flaws
18:00 SAST, false positive, pattern matcher, spell checker
22:52 IAST
25:16 it sucks to set up fuzzing currently in most cases
33:10 fuzzers, logical flows, API's [...], SAST, DAST, heartbleed
A
A
So,
basically,
the
ast
market,
as
defined
by
gardner
and
most
other
people,
includes
services
that
you're
going
to
use
to
test
your
code
for
security
vulnerabilities
and
that
usually
includes
a
mixture
of
sass
dust
fuzzing.
I
asked
sca
and
mobile
analysis
and
you
can
kind
of
see
what
those
all
stand
for
here.
A
If
you
look
at
this
list,
you'll
notice
that
we
have
everything
except
for
is
and
mast.
You
could
argue
we
kind
of
cover
mast.
I
won't
be
going
over
them
in
this
presentation
because
we
don't
have
them
as
part
of
our
ast,
but
if
you
have
questions
feel
free
to
pop
them
in
the
doc,
and
we
can
answer
them
at
the
end
so
who
exactly
supports
ast
here,
and
that
would
be
the
secure
and
defend
teams
where
secure
is
trying
to
make
sure
that
this
security
testing
is
occurring
earlier
on
in
the
process.
A
A
Do
what
we
want
it
to
do
and
not
do
what
it's
not
supposed
to
do
so,
the
first
one
on
the
list
is
sast
and
unfortunately,
this
one
kind
of
gets
the
nickname
spell
checker
a
lot
which
kind
of
rankles
some
of
us
here.
Other
people
have
just
learned
to
just
roll
with
it,
but
what
it's
doing
is
it
is
looking
at
your
source
code
and
looking
for
mistakes
in
that
code.
That
are
kind
of
easy
to
identify
by
patterns.
A
So
in
that
aspect
it's
similar
to
a
spell
checker
in
that
you
could
build
it
in
earlier
in
your
web
id
and
everything.
But
it
really
is
not
a
spell
checker.
It
can
find
something
like
a
sql
injection
which
again,
as
we
talked
about
similar
to
quality
people
put
in
o'hare,
when
you're
quality
checking
a
website
to
make
sure
you
can
handle
a
unicode
and
you
know
single
quotes
and
double
quotes,
and
everything
and
sas
is
gonna
say
well.
Are
you
just
taking
straight
up?
You
know
data
into
this
function?
A
That's
not
recommended!
You
should
be
handling
it
better.
The
risks
here
is
for
every
different
type
of
code
that
you're
using
you
kind
of
have
to
have
at
least
in
this
day
and
age,
a
different
tool
to
look
at
that,
because
languages
are
different.
A
So
secret
detection,
it
is
what
it
says
on
the
label
you're
looking
for.
Are
you
accidentally
leaking
secrets
that
you
shouldn't
be
so
this
should
could
be
an
api
token.
This
could
be,
you
know
a
implant
deployment
variable.
A
A
Then
you've
got
dust
which
a
lot
of
people
I
think
get
confused
about
dust
outside
of
you
know.
The
people
who
work
within
dust
is
okay.
Well,
that's
kind
of
like
sassed
right,
not
not
really.
Sas
is
looking
at
your
code.
Dest
is
looking
at
deployed
code
and
that's
really.
The
major
difference
is
like
here:
we've
got
the
review
apps.
A
So
it's
going
to
find
some
of
the
same
things,
but
many
more
different
things.
The
other
thing
with
dast
is
it's
going
to
be
much
more
language
agnostic,
because
it's
just
looking
for.
Can
I
have
running
codes?
I
don't
have
to
worry
about
looking
at
it
for
each
different
type
of
coding
standard,
and
I
I
think
the
frustrating
part
of
this
for
some
developers
is
like
it's
going
to
tell
you
on
this
website.
A
I
found
this
problem,
but,
as
you
all
know,
when
you're
writing
a
website
page,
it
could
be
using
tons
of
different
functions
located
all
over
your
your
code
base.
So
you
might
be
like
okay
well,
which
one
of
that
caused
it,
which
I'll
just
quickly
allude
to.
I
asked
is
supposed
to
help
with
that
problem.
We
don't
have,
I
asked
here,
but
it's
supposed
to
kind
of
make
it
so
that
you
can
better
identify
where
things
are
coming
from.
A
So
it's
kind
of
what
people
consider
like
the
next
generation
or
the
step
up
all
right
and
then
you've
got
dependency
scanning,
and
this
is
because,
I'm
sure
you
all
know
today,
you
don't
reinvent
the
wheel
or
really
it's
not
ideal,
to
reinvent
the
wheel
constantly
so
you'll
find
this
particular
library.
This
particular
resource
has
already
solved
this
problem
for
me,
so
I'm
going
to
bring
it
into
my
project.
A
Many
projects
today
are
more
than
50
third-party
code.
Well,
when
you're,
relying
on
a
whole
different
team
of
people,
they're
going
to
introduce
vulnerabilities,
just
like
you're,
potentially
going
to
introduce
vulnerabilities
and
those
get
disclosed
through
usually
public
methods,
which
would
be
like
a
cve
number
or
it
could
just
be
disclosed
to
their
own
mailing
list.
A
A
Some
scanners,
not
rs,
actually
check
to
see
that
you're,
using
the
impacted
function,
which
makes
them
a
little
bit
fancier
ours
currently
is
just
looking
for,
is
the
whole
version
that
you're
looking
at.
I
got
the
risks
in
there
all
right
and
then
we've
got
container
scanning
right
now.
It's
awesome
to
deploy
things
out
to
containers.
A
You
can
just
pop
things
on
send
them
out
agnostically
to
your
amazons
or
your
googles,
and
you
know
it
manages
your
clusters
for
you.
You
don't
have
to
worry
about
your
your
hardware.
The
risk
with
that
is.
You
are
not
maintaining
that
operating
system
you're,
not
maintaining
that
server
anymore
and
you're
reliant
on
an
image
which
usually
has
a
particular
operating
system,
certain
dependencies
that
have
to
come
pre-installed
for
your
software
to
work.
A
So
what
container
scanning
is
doing
and
in
our
particular
case
we're
doing
pre-deploy
scanning
not
post,
deploy
scanning.
That
would
be
more
of
like
a
defend
thing.
To
look
at
a
deployed
container
but
are-
and
you
can
think
about
like
dependencies-
are
the
pieces
that
are
within
this
container
that
make
up
this
image,
have
known
vulnerabilities
or
known
issues,
and
if
they
do,
then
it's
like
hey.
You
should
maybe
update
to
a
newer
image
or
update
this
particular
piece
of
this
image,
because
that's
going
to
be
a
risk
once
it's
deployed.
A
And
the
last
one
is:
we
have
license
complaints,
you'll
notice,
that
was
not
included.
So
when
they
talk
about
ast,
it
does
not
include
license
compliance
license.
Compliance
more
relates
to
what
licenses
are
you
using,
and
you
will
probably
hear
the
term
s-bom
s-b-o-m
software
bill
of
materials
when
people
are
talking
about
this
so
for
the
acronym
soup,
I'm
just
tossing
that
one
in
there.
If
you
hear
s-bomb,
license
compliance
if
you're
ast,
that's
going
to
be
those
other
things
from
earlier,
and
the
new
and
exciting
thing
that
we
have
is
fuzzing.
A
So
I
consider
fuzzing
not
to
be
the
first
thing
that
you
should
deploy
in
your
environment
because
it's
going
to
find
a
lot
of
things,
but
definitely
once
you've
got
like
your
sas
door
desk,
introduce
fuzzing,
and
what
fuzzing
does
is
it's
looking
for
when
I'm
sending
things?
How
is
the
application
responding
and
what
I
mean
by
that
is:
is
there
something
that
we've
done
that
allows
for
a
memory
leak?
A
Is
there
some
kind
of
business
logic
flaw?
Is
there
unexpected
occurrences
and
kind
of
like
I
was
saying
earlier
this
pairs
with
qa?
It's
not
just
about.
Can
I
have
an
app
that
works?
It's
can.
I
have
an
app
that
works
that
doesn't
respond
poorly
to
unexpected
or
malformed
content
or
unexpected
formats
of
content?
Does
somebody
try
and
put
an
emoji
in
a
form
and
does
my
form
suddenly
explode
when
I
do
that?
That's
not
a
good
thing
and
you
need
to
know
about
that,
and
the
nice
thing
is
fuzzing.
A
B
In
contrast,
fuzzing
is
exercising
the
program
in
all
sorts
of
strange
and
odd
ways,
so
it's
going
to
find
bugs
that
traditional
qa
processes
won't
just
because
it's
trying
things
that
your
testers
or
your
scanners
didn't
think
to
look
for
another
point
to
add
on
to
there,
because
I
think
on
the
slide,
it
said
this
was
done
in
production.
Primarily,
you
can
actually
do
fuzzing
on
parts
of
the
application
earlier
in
the
life
cycle.
A
A
C
Are
there
some
ones
that
commonly
lead
to
confusion
on
what
the
scanner
does
and,
like
example,
all
these
is?
I
I've
heard
people
we
talk
about
our
customers.
Talk
about
our
sas
is
if
it's
a
das
offering
so
they
said
things
like.
Oh
with
our
sas,
you
can
find
the
sql
injections
in
your
app
all
that's
running.
It's
like
well
that
that's
not
really
the
case.
You
know
sas
is
by
definition,
static.
C
A
Yeah,
I
think
we
should
definitely
rotate
through.
I
will
echo
that
I
think
when
I
give
presentations,
there's
definitely
a
lot
of
confusion
about
what
is
dast
versus
what
is
sas
and
at
which
juncture
do
they
run
because
a
lot
of
people
are
like?
Oh,
can
I
run
dust
while
I'm
coding
it's
like
you
got
to
have
a
you,
could
have
a
test
environment.
You
could
have
like
a
pre-prod
environment,
staging
environment.
You
have
to
have
something
for
it
and
it's
like.
Oh,
you
know
like
the
the
sas
that's
going
to
catch.
A
You
know
something
in
my
configuration.
It's
like
not
really,
because
your
configuration
tends
to
occur
either
in
the
way
in
which
you've
deployed
or
in
your
running
environment.
That's
not
something
you're
going
to
catch,
because
somebody
set
bit
to
true
for
a
particular
variable,
like
that's,
that's
a
little
too
advanced
for
a
sas
engine.
A
I
think
also
just
people
just
have
no
idea
what
fuzzing
is
absolutely
no
idea
whenever
I
give
a
presentation,
but
something
that
they
relate
to,
and
you
could
in
theory
do
it
as
part
of
das,
so
dast
is
extensible
and
you
can
give
it
different
payloads
but
they're
not
specifically
designed
to
try
all
of
the
options.
It's
meant
to
try.
A
What
are
the
common
options,
whereas
fuzzing
is
I'm
going
to
try
a
huge
breadth
and
depth
of
two
long
fields,
different
character,
type
fields,
different
code
type
fields,
and
so
people
don't
exactly
grasp
the
difference
in
there,
but
you're
looking
for
a
different
type
of
response,
and
that
type
of
response
is
unexpected
things
that
a
quality
person
is
not
necessarily
going
to
have
considered
of.
I
should
test
this
field
like
if
I'm
quality,
I'm
going
to,
say
I'm
going
to
try
a
number
in
the
letter
field,
or
vice
versa.
C
I
think
it
would
be
good
for
sam
to
elaborate
on
this,
but
like
the
one
of
the
main
things
that
sam's
gonna
be
focused
on
with
fuzzing,
is
you
know,
coverage
guided
buzzing
which
can
be
done
earlier?
You
don't
need
the
review
out
and
I
think,
like
from
the
interviews
we've
done
so
far
and
all
those
briefings
that
everybody
assumes
that
we're
tacking
on
buzzing
to
the
end.
So
it's
kind
of
like
where
the
security
team
has
the
final
build.
That's
going
to
go
public
and
that's
not
really.
C
A
So
that
was
me,
I
think
all
the
pms
should
pitch
on
that
one.
That's
just
the
stuff
when
I've
given
presentations
and
that
by
the
way,
those
slide
decks
with
the
cute
animals
or
from
presentations
like
given
at
conferences.
I'm
recycling
says
sam
and
then
taylor
and
do
we
have
anybody
else
hiding
go.
B
In
that
order,
yeah
I'll
I'll
echo
a
lot
of
the
points
nicole
ray's,
certainly
for
me,
I
especially
hear
the
what
is
fuzzing
question.
Quite
often,
I
think
we
have
a
lot
of
work
to
do
in
terms
of
education
and
just
the
market
and
the
security
space
in
general,
because
a
lot
of
what
people
remember
is
fuzzing
is
very
antiquated
from
pre-2010
or
even
in
the
90s.
B
Some
of
these
concepts
were
invented
and
so
kind
of
to
david's
point,
a
more
general
sense
of
shifting
security
left
and
using
security
as
part
of
the
developer.
Workflow
is
where
I
see
a
lot
of
misconceptions.
B
Security
is
not
something
that
we
at
gitlab
think
should
be
bolted
on.
At
the
end,
where
security
is
testing
the
build
before
it
goes
to
production,
it
really
should
be
for
all
of
these
scanners,
something
the
developers
are
doing.
They
should
be
running
sas
as
part
of
their
builds.
They
should
be
running
gas
on
their
applications.
D
D
I
think
this
is
where
people
give
it
too
much
credit
and
think
it
smarter,
or
does
things
that
it
doesn't
do
so
I
actually
explain
what
is
dashed
more
than
anything,
because
people
think
that
dast
is
sassed,
and
I
think
that
kind
of
sets
up
this
logical
fallacy
where
people
think
that
sast
is
a
magical
solution,
and
so
why
does
it
have
all
of
these
false
positives?
And
so
it
it?
F
You
know
actually
david,
since
she
brought
up
the
spell
checker.
That's
a
common
thing
that
we
get
asked
about
and
the
the
main
difference
that
other
appsec
vendors
have
that
we
don't
is
that
it's
a
plug-in
into
other
ides
and
and
so,
if
you're,
using
visual
studio
or
something
it
can.
F
Other
vendors
can
can
tell
you
that
you're
typing
something
that
is
a
potential
vulnerability.
I
think
it
gets
annoying
for
the
developers-
and
it's
often
referred
to
as
sas
light,
because
it's
not
a
full
sas
scan.
So
it's
only
going
to
detect
a
small
subset
of
things
so
really
the
if
you're
a
salesperson
watching
this.
The
better
argument
would
be.
F
C
I
mean
to
add
to
that,
because
that
that
came
up
on
our
briefing
yesterday
and
even
though
I
will
say
it
was
about
buzzing,
but
that
question
was
asked.
I
the
the
response
that
works
really
well
kind
of,
as
what
cindy
just
said
is
like.
Yes,
it's
on
our
roadmap.
The
intent
is
to
be
able
to
provide
real-time
sash
results.
I
know
jayla's
looking
at
ways
to
do
that
today,
however,
our
sas
scans
run
phenomenally
quickly
like
they.
Just
that
can't
be
stressed
enough.
C
They
ask
it
to
run,
and
I
will
point
they
also
sit
down
and
buy
two
licenses,
so
the
developers
will
rotate
who
gets
to
run
the
stand,
whereas
our
start
runs
in
pipeline
and
if
you're
making
commits
regularly
like
good
development
best
practices
are
you'll,
be
getting
results.
C
Really
quickly
and
be
able
to
address
them
while
you
have
switched
contacts,
so
I
made
a
joke
about
the
spell
checker
because
nicole
brought
it
up,
but
you
know
it's
one
of
those
where
I
I
can
see
where
we
would
want
to
go
with
it,
but
in
the
short
term
that
can't
be
stressing
up
how
fast
our
skins
run
and
how
you
actually
get
that
value
really
quickly.
You
have
to
wait
forever.
A
A
So
even
if
you
have
that
a
everyone
on
your
team
may
want
to
use
a
different
ide
and
we
may
not
have
plug-ins
in
the
future
for
everything
and
I'm
pretty
sure
all
you
know,
there's
a
they
keep
popping
up,
there's
more
ids
all
the
time.
So
you
said
you
know,
go
for
game,
but
also
don't
like.
If
you
pass
that
you
know,
that's
not
saying
you're
perfect,
that
was
a
subset
of
checks
that
could
be
done
while
you
were
typing.
A
A
F
Nicole,
it
might
be
worth
pointing
out
too
that,
even
though
we
don't
have,
I
asked
our
dast
somewhat
fulfills
the
objective
of
what
why
is
was
created.
So
I
asked
was
the
means
of
doing
dynamic
scanning
earlier
in
the
life
cycle
to
make
it
more
interactive
for
the
developer.
F
Guess
what
we
do,
that
we
do
it
with
a
review
app,
so
we
just
approach
it
differently
to
solve
the
same
sort
of
problem.
What
we
don't
do
is
instrument
the
app
which
actually
is
people,
don't
like
their
apps
to
be
instrumented,
because
there's
lots
of
different
instrumentations
and
so
just
might
be
worth
worth,
pointing
out
that
our
approach
to
solve
that
challenge
is
a
little
different.
A
E
B
C
B
Question
I
would
love
to
discuss
if
there
are
things
that
are
less
ambiguous,
we
refer
to
it
as
either
fuzzing
or
fuzz
testing.
I
think
that's,
actually
the
closest
we'll
be
able
to
get
in
terms
of
describing
what
we're
trying
to
describe
here.
I
think
it's
just
going
to
be
a
thing
of
this
needs
to
become
a
more
common
topic
of
conversation,
so
that
the
term
that
term
becomes
more
well
known
to
people,
because
fuzzing
is
not
incredibly
widely
used
right.
B
A
And
I
might
be
overstating
it,
but
a
lot
of
security
people
when
they
go
through
certain
trainings,
absolutely
learn
about
fuzzing,
but
the
one
thing
that
I'm
kind
of
excited
about
is:
can
I
curse
on
youtube?
I
will
bleep
myself
it
sucks
to
set
up
fuzzing
currently
today,
in
most
cases
really
really
sucks
to
set
it
up,
and
so
there
are
a
lot
of
sas
tools
that
are
easier
to
set
up.
A
There
are
a
lot
of
das
tools
to
set
up
and
because
fuzzing
is
usually
in,
and
I
don't
want
to
like
downplay
it,
but
it's
usually
a
additional
set
of
findings
that
are
being
found.
You're
like
well,
I'm
already
finding
findings
a
and
b
and
there's
a
ton
of
those
so
I'll,
I'm
going
to
keep
putting
off
fuzzing,
which,
when
it's
painful
you
know,
everybody
likes
to
delay
that
pain.
A
A
You
know,
like
I'm,
finding
some
findings
here,
I'm
finding
some
findings
here
and
I'm
finding
some
findings
here
and
I
have
to
correlate
them
all
of
our
tools,
find
them
and
put
them
in
the
dashboard
for
you
together
and
put
them
in
the
mr
for
you
together.
So
it's
not
going
to
be
like.
I
need
to
set
this
up,
and
so
one
aspect
people
don't
actually
have
to
understand
that
this
result
came
from
fuzzing.
A
You
know
they
just
need
to
know.
This
was
a
vulnerability
that
was
found,
and
so
I
definitely
think
we
could
blog
and
educate
people,
but
on
the
other
hand,
in
the
end
you
as
a
developer,
do
you
care
if
it
came
from
sas
desk
or
fuzzing,
or
do
you
care
that
hey
this
piece
of
code
that
I
wrote
has
this
particular
risk
associated.
E
Yeah,
I
think,
like
from
my
own
experience.
I
think
I've
actually
used
fuzzing
tools
without
realizing
it
was
a
fuzzing
tool,
like
the
two
that
come
to
mind
was
wp
scan
and
nicto
like
I've
used
these
tools,
but
I
don't
know
if
they're
like,
if
that
constitutes
its
fuzzing
in
those
cases
I
was
looking
for
unpatched
wordpress
plugins
and
for
vulnerabilities
on
a
web
server
by
just
attacking
you
know
what
was
available.
E
I
think
those
are
forms
of
fuzzing.
Those
are
manual
steps
that
I
had
to
take,
and
so
maybe
I've
already
fuzzed
my
own
things
without
realizing
it
was
fuzzing
and
that's
the
the
bridge.
So
if
we
were
to
like
take
known
tools
and
say
these
are
examples
of
fuzzing
tools
that
you
don't
have
to
go
set
up
yourself
yeah,
I
think
the.
C
Some
of
those
tools
are
best
tools
and
there
are
tools
in
the
dash
space
that
will
do
lightweight
fuzzing.
I
think
that's
the
the
challenge
remote
is
more
like
opposing
product
is
doing
way
more
than
what
nicto
or
wp
scans
going
to
do.
C
It
doesn't
make
those
other
tools,
not
good
right,
because
those
tools
are
going
to
do
things
that
the
fuzzing
tool
is
not
going
to
do
like
try,
sequel
injections
and
then
right
so
request
forgeries
and
all
that
kind
of
thing.
So
I
think
the
the
real
challenge
that
sam's
going
to
have
as
he
moves
forward
with
you
know.
C
The
recent
acquisitions
and
integrating
them
in
is
making
sure
people
understand
the
value
across
each
of
the
tools,
because
I'll
echo
what
nicole
said,
I
think
in
a
lot
of
our
customers
cases
they're
not
saying
I
need
a
sass
tool.
I
need
a
basketball
they're
saying
how
do
you
know
what
my
vulnerabilities
are
and
to
them?
C
It's
good
that
they
know
we
have
the
different
tools,
but
as
long
as
the
tools
are
providing
quality
output
and
working
as
we
expect,
I
don't
know
if
they
care
that
the
finding
came
from
one
versus
the
other,
but
you're
you're,
highlighting
on
a
on
a
key
problem.
There
are
a
lot
of
the
web
vulnerability
scanners
in
the
dash
space
that
will
also
occasionally
just
throw
in
garbage
to
see
what
happens.
C
That's
a
that's
a
lightweight
fuzz,
but
that's
not
to
the
extreme
of
like
what
a
rest
api
based.
Fuzzer
is
going
to
do
or
what
the
protocol
puzzle
that
we
just
required
also
also
does.
F
F
If
you've
after
you've
done
sass
and
you've
done
das,
then
you
might
look
at
fuzzing
you're,
probably
not
going
to
start
with
fuzzing,
if
you
don't
have
the
others
right,
and
so,
if
I'm
already
finding
10
000
vulnerabilities
with
sas
and
das,
I
don't
want
to
find
any
more.
I've
got
all.
I
can
deal
with
right.
So
in
some
cases,
if
you
just
look
at
it
as
an
additional
layer
of
scanning
to
find
additional
vulnerabilities,
it's
kind
of
a
nice
to
have,
but
not
a
necessity.
A
Once
it's
easy
to
set
up,
it's
no
longer,
in
my
opinion,
a
nice
to
have.
If
you
want
to
have
comprehensive
security
coverage,
you
have
to
turn
on
all
of
the
different
ways
of
looking
for
vulnerabilities
once
it's
easy,
which
is
our
goal
and
then
from
there
we
need
to
help
with
prioritization.
So
maybe
you
can
say
I'm
going
to
ignore
everything.
That's
that's
not
a
critical
and
just
not
look
at
those
and
concentrate
on
wherever
it
came
from
here's.
A
F
But
it's
harder
to
justify
an
incremental
budget
for
comprehensive
testing,
because
a
lot
of
people
feel
like
I
I'm
already
finding
a
bunch
of
vulnerabilities.
That's
got
to
be
good
enough
and
that's
why.
So,
when
you
look
at
the
you
know,
they're
going
after
budget
to
get
to
ultimate
and
that's
a
big
jump,
it
really
has
to
be
a
a
necessity
and
and
with
a
clear
compelling
purpose,
and
I
think
something
like
apis
is-
is
really
important.
There.
B
B
Given
api
calls
will
always
have
sql
injection
if
you
just
use
input
directly,
that's
just
a
fact
and
every
sas
scanner
will
find
it.
A
fuzzer
is
going
to
find
the
logic
where
your
developer,
on
a
given
calendar
day
with
a
given
input,
configuration
there's
a
subtle
bug
and
that's
really
the
the
thing
that
fuzzing
is
going
to
find
and
we
can
emphasize
rather
than
how
it's
being
done,
the
value
the
results
are
going
to
bring
to
your
org,
and
I
think
that's
a
really
good
point
to
highlight.
B
A
Conversely,
you
can
also
look
at
the
cost,
sometimes
that
small,
one-off
flaw
can
be
so
damaging
an
entire
industry
of
system
administrators
lose
a
week
of
their
life.
Please
see
heartbleed,
which
was
found
via
buzzing
and
would
not
have
been
found
otherwise,
and
the
delay
in
that
being
found
led
to
it
being
pervasive
everywhere,
which
led
to
many
system,
administrators
and
companies
spending
a
lot
of
money
and
a
lot
of
time
to
mitigate
the
results
of
that.
A
B
Yeah,
the
the
reason
I
use
that
calendar
analogy
was
because
there,
a
few
months
ago,
there
was
a
stock
broker
brokerage
application
that
went
down
because
they
didn't
handle
leap
years
correctly.
That's
not
at
all.
Well,
it
could
be
a
security
issue,
but
it's
not
really
a
security
issue.
In
this
instance,
it's
just
a
subtle
logic
flaw
where
their
traditional
qa
processes
missed
it.
I
would
posit
that
fuzz
testing
would
have
found
that
if
they
had
used
it
against
the
various
parts
of
the
app
that
were
responsible
for
it.
E
Yeah
crypto
and
time
and
ntp
and
synchronization
those
are
all
important
things.
I
want
to
ask
a
question
from
the
perspective
of
that
openssl
or
just
like
an
open
source
developer.
So
if
I'm
building
a
project,
that's
like
a
command
line
interface
versus
an
http
api
versus
like
a
cms
web
product.
Would
you
provide
me
different
guidance
on
like
where
I
should
probably
start
in
terms
of
like
providing
some
level
of
vulnerability,
analysis
or
like?
I
don't
want
to
be
that
open,
ssl,
developer
who's.
You
know
committing
code
on
new
year's
eve.
E
You
know
1990
whatever
to
then
have
you
know
led
to
what
was
effectively
heartbleed.
So
would
you
provide
me
guidance
based
on
the
type
of
project
that
I'm
doing,
and
where
would
I
find
that
guidance.
A
So
I'm
not
sure
if
type
of
project
is
the
right
thing,
but
I
would
look
at
any
one
of
the
threat,
modeling
and
risk
modeling
standards
where
you're
looking
at.
Where
is
the
important
data
stored?
So
look
at
gitlab,
we
classify
our
data
by
color,
you
know
so
anything
touching.
The
riskiest
data
gets
the
most
scrutiny
so
for
an
example.
If
it's
command
line
any
command
that
I
can
run,
that's
going
to
be
destruction,
or
you
know
like
that.
A
You're
going
to
want
to
concentrate
on
so
depending
which
tool
you're,
looking
at
depending
on
your
interface
in
a
website
that
you
know,
allows
you
to
place
orders
you're
going
to
put
the
most
scrutiny
on
like.
How
can
I
see
people's
credit
card
information
or
how
does
the
money
exchange
happen?
Because
that's
where
damage
happens
then,
after
that
you're
going
to
look
at?
How
do
I
protect
pii?
A
Because
that's
going
to
get
me
fines,
and
so
it's
all
about?
Where
is
your
danger?
Where
is
your
risk?
That's
where
I'm
going
to
concentrate
so
destructive
actions,
leaking
of
data
credit
card
numbers,
and
so
you
just
pick
those
commands
or
that
api
call
or
that
web
page,
and
you
start
with
that
as
your
your
focus
and
then
once
you
figure
out,
that's
my
focus.
The
best
tool
for
that
is
x.
E
I
I
could
hear
her
yeah
she
just
stuck
here
today.
I
I
think
like
what
I'm
asking
is
like
how
does
git
lab
help
me
like
why?
Why
should
I
use
git
lab,
as
opposed
to
hosting
my
open
source
project
elsewhere,
like
what
can
gitlab
do
to
help
me
figure
out
the
best
things
to
start
with
because
you're
talking
about,
we
talked
about
like
okay,
maybe
I'd
start
with
dependency
scanning
and
then
the
next
layer
is
this.
The
next
layer
is
this,
but
it
might
be
different
based
on
if
it's
an
api.
E
C
Yeah,
so
to
your
question,
really,
I
think
the-
and
this
is
where
we
could
probably
do
a
good
job
on
either
direct
the
direction
page
or
even
in
a
blog
just
so
you
know
somewhere
online
like
it
like
your
example
was
like
I'm
writing
something
as
a
cli.
It
doesn't
have
a
web
interface.
What
do
I
like?
What
should
I
be
doing,
and
I
would
say,
like
the
the
static
analysis,
solutions
that
we
offer
would
be
where
that,
where
you'd
want
to
start
right,
so
you
could
begin
using
sas,
which
obviously
is
gonna.
C
C
I
think,
once
you
get
to
a
point
where
you
have
a
running
service
or
some
sort
of
interface,
if
it's
the
command
line
off
the
top
of
my
head,
I
can't
point
to
one
specific
thing
because,
like
the
next
thing
would
be
like
a
das
type
solution,
but
I
do
see
a
path
to
where
we
could
potentially
fuzz
a
cli
interface
in
a
review
app
right.
So
your
app
comes
up
and
we
can
begin
to
interact
with
it
there
locally.
C
If
you
do
have
some
sort
of
services
running,
that's
where
you
can
be
in
a
leveraged
ass.
So
if
it's,
whether
it's
a
api,
a
web
web
app
like
that's
where
you're
starting
into
that
areas
of
das
task
api,
any
api,
fuzzing
and
and
outside
of
that,
and
actually
I
should
say
that
that
stack
announcement
you
could
be
using
container
scanning.
You
could
be
using
dependency
scanning
right.
C
So
there's
a
lot
of
things
you
can
be
doing
but
like
as
soon
as
you
have
one
line
of
code,
you
can
begin
running
sas,
and
so
I
gave
the
example
to
a
friend
who
was
doing
database
development,
but
their
app
wasn't
up
and
running
yet,
and
I
said
like
look
like
right
there,
you
wrote
a
sql
statement.
You
could
have
sas,
tell
you
whether
that
was
written
securely.
C
C
B
One
thing
I
would
like
to
add
on
to
that,
because
when
I
first
started
gitlab,
this
is
one
of
the
things
that
made
me
most
excited
our
auto
devops
processes
have
all
of
our
security
scanning
built
into
them
from
day
one.
If
you're
a
project
maintainer
with
either
an
open
source
or
proprietary
project,
you
don't
have
to
learn.
Gitlab
ci,
you
don't
have
to
learn
our
security.
B
Auto
devops
will
do
all
of
that
for
you
right
out
of
the
box,
and
I
think
that's
one
of
the
really
compelling
things
that
we
have
versus
a
lot
of
the
other
solutions
out
there
in
the
market
is
to
david's
point
about
doing
static
scanning.
You
don't
need
to
set
up
your
kubernetes
to
host
your
apps
to
review
applications.
Auto
devops
gives
you
sas
container
scanning
all
the
other
things.
Then,
as
you
figure
out
your
application,
matures
you
understand
how
to
host
with
git
lab
all
of
the
das
and
the
other
more
advanced
security
scans.
B
E
C
I
think
that
I
I
can't
remember,
I
said
this
during
my
weekend.
Conversations
personally,
I
feel,
like
I've,
said
this
a
lot
though,
but
maybe
they've
said
to
myself,
but
we're
in
a
very
unique
position
to
sam's
point
to
be
a
true
security
partner.
C
E
I
think
it's
an
educational
tool
yeah
for
someone
who
doesn't
know
what
these
acronyms
are
just
to
enable
auto
devops
and
see
that
they
exist,
and
then
that
leads
to
pages
on
on
gitlab
stock,
to
understand
more
about
what
that
is,
because
if
I'm
a
developer
in
a
non-technical
domain,
let's
say
finance
or
healthcare.
You
know
these
are
things
that
may
not
be
known
to
me
and
so
having
gitlab
guide
me
towards
these
practices
and
improving
our
software
helps.
So
I
love
that
we
we
use.
We
have
actually.
A
Dovetails
perfectly
to
the
next
question,
which
is
well
no
like
I'm
stealing
it,
because
it's
a
great
segue.
So
the
question
is
how
much
are
people
actually
looking
for
a
specific
type
of
scanning
and,
like
you
had
mentioned,
like
healthcare
or
other
things
like
if
I'm
in
fintech
or
if
I'm
in
healthcare,
I
may
have
a
qsa
or
an
auditor
or
a
compliance
person
come
in
and
say
you
must
have
sassed,
you
must
have
dust
or
they
could
just
say
you
have
to
have
ast.
A
And
so
I
think
those
people
who
are
saying
I
just
want
x
are
an
opportunity
for
all
of
us
to
kind
of
educate
them
of
like
yeah.
We
can
totally
give
you
x,
but
that's
one
way
of
looking
at
your
code
and
you
really
should
implement
all
of
them,
so
you're
protecting
yourself
throughout
your
entire
process
and
you're.
Looking
at
the
code
from
all
the
different
angles
and
yes
we'll
totally.
A
We
have
that,
but
because
of
our
pricing
model
like
you
get
all
of
the
different
security
tools
within
ultimate
and
you
can
use
all
of
those.
So
there's
no
reason
for
you
not
to,
whereas
with
some
other
tools
it's
by
scan-
or
you
know
whatever
and
so
you'll
get
penalized
by
lines
of
code
or
types
of
scans
and
we're
just
like
you
have
paid
for
ultimate
for
your
developers,
and
so
please
use
it
and
get
better
coverage.
A
B
I
think
another
good
point:
there
too,
is
a
lot
of
other
products
and
solutions
out
there
in
the
market
they're
going
to
up
charge
for
additional
security
scans,
which
makes
it
kind
of
a
friction
point
between
orgs
want
to
do
more
security
scanning.
But
that
means
they
need
more
budget
to
do
an
additional
type
of
scan,
or
do
it
more
places
inside
their
organization
with
gitlab,
because
we're
providing
all
of
our
scanners
in
the
same
licensed
here
in
ultimate.
B
That
makes
it
a
non-issue
a
non-friction
point
of
we
really
do
want
to
help
you
be
that
be
that
security
partner
for
our
customers
and
encourage
that
best
security
practice
without
having
to
make
the
having
to
put
a
choice
to
our
users
of.
Do
you
want
better
security
or
do
you
want
to
deal
with
budget
and
resourcing
issues
and
that
lets
them
grow
into
those
best
practices
over
time
rather
than
have
to
you
know,
continually
figure
out
is
each
individual
new
scanner,
something
they
want
to
spend
more
money
on.
E
I
remember
pitching
to
a
team
like
wanting
to
set
up
cruise
control.
This
was
like
the
first
continuous
integration
server
that
I
had
ever
worked
with
and
at
that
time,
ci
was
like
what.
Why
would
you
want
to
spend
time
integrating
your
code
and
now
today,
ci
is
so
normal.
How
could
you
not
want
ci
in
in
your
software
engineering
development
practices,
and
so
I
kind
of
think
we're
at
the
cusp
of
that
with
some
of
these
security
tools
as
well,
but
it's
not
normalized
in
regular
developer
culture
because
it
does.
E
D
Yeah,
so
when
you
look
at
all
of
our
sas
scanners,
they're
all
open
source
tools,
anyone
can
literally
go
download
them,
run
them
in
their
environment.
So
we
get
this
argument
a
lot
of
well.
I
could
go
do
that,
so
why
would
I
pay
for
an
ultimate
license
to
do
it?
True,
you
can
go,
do
that
and
have
fun
going
and
spinning
up
18
scanners
and
getting
them
to
run
and
deciding
when
to
run
them
and
the
cost
associated
with
running
them
or
you
could
just
have
them
integrated.
D
However,
that
doesn't
include
the
full
suite
of
ultimate
features,
so
basically,
core
customers
will
soon
be
able
to
trigger
the
scanner,
configure
the
scanner
and
see
the
json
object
that
the
scanner
creates.
They
won't
get
the
nice
security
ui,
they
won't
get
the
mr
widget,
the
security
pipeline,
the
security
dashboards,
all
the
things
that
make
it
easy
to
interact
with
those
security
vulnerabilities
and
then
to
do
things
like
see,
dashboards
and
the
status
and
roll-ups,
and
all
of
that
kind
of
thing.
Around
security
vulnerabilities.
B
Yeah,
to
add
on
to
that
I
mean
it's
a
great
question,
because
certainly
if
security
feels
like
a
paywall
folks
won't
use
it
all
of
our
features
in
defend
initially
came
out
as
part
of
core,
so
the
the
waff
that
we
released
in
the
fall
of
last
year
that
was
released
into
core
from
day
one.
Just
like
all
the
great
stuff
taylor
was
talking
about
we're
going
to
add
new
value.
C
Yeah,
by
the
way,
like
everything
now
technically
in
defend,
is
in
core
because,
like
vulnerability,
management
moved
over
to
secure,
which
is
an
ultimate
but
yeah
you're
right,
yeah,
container
network
security,
its
base,
offering
is
in
core
container
host
security,
is
getting
ready
to
ship.
That's
gonna
be
in
core
on
its
first
release
and
as
sam
mentioned
waff
is
there
already.
C
The
thing
I
was
surprised
him
didn't
mention
is
that
some
of
the
fuzzing
stuff
is
also
going
to
be
in
core
when
it
becomes
available,
so
the
coverage
guided
fuzz
engines
are
going
to
be
in
core.
So
what
we're
really
trying
to
do
is
build
a
path
for
people
to
understand
their
security
posture
as
skeleton
using
what's
available
today
in
open
source
making
that.
C
Show
them
the
value
to
upgrade
ultimate
as
taylor
and
sam
hill,
like
we've
taken
time
to
build
out
custom,
workflows,
interpretation
of
results,
duplication
of
results.
Nobody
that's
working
on
dash
days
on
the
call,
but
desk
is
a
great
example
of
like
you're
going
to
have.
100
findings
are
really
the
one
finding
and,
if
you're
just
using
the
open
source
tool,
you
would
know
that,
but
we're
building
in
that
intelligence
to
be
able
to
duplicate
that
stuff.
C
For
you,
as
well
as
add
other
value
like
some
of
the
acquisitions
we've
had
and
so
forth,
that
will
live
in
ultimate
homeland,
so
I
definitely
think
mo
like
we.
It
sounds
like
we
paid
you
before.
This
call
to
bring
up
all
the
good
things
we're
doing.
So,
whoever
owes
you
the
five
bucks
for
that
make
sure
you
get
it
after
the
call.
But
you
know
it's
like
we're
doing
everything
that
you
want
or
you're
asking
about.
A
And
kind
of
a
quick
add-on
to
that
one
of
the
fuzzing
companies,
like
is
very
well
known
for
their
community
edition,
so
that
sort
of
was
already
out
and
about
and
is
continuing
to
be
out
and
about,
but
they
always
had
an
enterprise
edition
before
and
that
kind
of
division
will
continue,
but
it'll
be
ultimate
core
kind
of.
If
the
terminology
will
change,
the
idea
stays
the
same
and
we
are
at
our
five
minute
warning,
so
everyone,
I
think,
shoe
and
then
mo.
We
can
discuss
the
last
question
later.
If
you
want.