►
From YouTube: Writing Secure Node Code: Understanding and Avoiding the Most Common Node.js Security Mistakes
Description
Writing Secure Node Code: Understanding and Avoiding the Most Common Node.js Security Mistakes - Guy Podjarny, Snyk
A
Hi
everybody
thanks
for
waking
up
this
morning,
so
to
be
in
second
session
here:
I'm
guy
pajara,
our
guy
poet,
sneaked
and
I'm
here
today
to
talk
about
security,
to
talk
about
writing,
secure,
node
code
just
for
context.
A
little
bit
of
history
about
me
is
I,
am
at
guy,
but
at
Twitter
right
now,
I
work
on
snake.
The
deals
with
open
source
security
and
I
have
a
lot
of
experience
in
the
web
security,
space,
application
security
and
the
web
performance
space.
A
So
javascript
is
awesome
right,
I
think
everybody
said
it
here
would
probably
concur
you're
sort
of
coming
to
this
office
this
conference
and
we
like
to
talk
about
how
javascript
has
won-
and
you
know
it's
kind
of
the
dominant
language
in
many
metrics
and
there's
a
lot
of
reasons
for
it.
There
are
a
bunch
of
these
notable
JavaScript
traits
that
we
can
point
out
that
make
it
great
like
some
built-in
memory
management.
So
we
don't
worry
about
that
as
compared
to
maybe
some
other
languages
has
some
built-in
native
serialization
like
Jason.
A
It's
naturally
scalable
and
a
variety
of
other
properties
that
make
it
powerful
that
make
us
productive
and
it'll
build
in
it,
and
these
are
great
and
they
make
us
productive,
but
sometimes
the
very
things
that
make
JavaScript
awesome
make
node
awesome,
also
make
it
vulnerable.
So
you
might
look
at
that
list
and
talk
about
the
productivity,
but
I.
Look
at
that
list
and
I
might
see
some
flaws.
I
might
see
some
potential
security
risks.
If
you
have
built-in
memory
management,
but
is
that
comprehensive
is
there
are
places
where
you
might
leak?
A
Some
information
out
can
I
manipulate
types
in
this
dynamic
typing
environments
and
triggers
and
vulnerabilities
there's
a
bunch
of
these
types
of
flaws,
and
it's
important
as
we
build
applications
in
JavaScript
to
be
aware
of
those
and
to
try
and
avoid
them
to
the
extent
we
can
the
so.
A
lot
of
this
talk
is
going
to
be
around
those
components,
but
another
important
piece
of
context
is
that
these
types
of
capabilities,
as
well
as
flaws,
are
not
just
in
your
own
code.
A
A
Every
time
I
need
to
update
it
just
in
terms
of
sheer
volume,
and
it
leads
to
the
situation
where
this
is
your
app,
and
this
is
your
code,
and
you
know
I
like
to
kind
of
point
out
that
this
might
seem
like
a
negative
slide,
but
it's
actually
a
positive
slide,
because
all
you
have
to
do
is
write
that
little
purple
dots
to
get
all
of
that
orange
ish
value,
and
it's
a
good
thing.
But
it's
also
a
scary
thing.
It
also
implies
some
diminished
controlled.
A
So
most
of
your
applications
code
comes
from
NPM,
which
also
means
most
of
your
applications.
Vulnerabilities
come
from
NPM
from
all
this
code
that
you're
pulling
it
that
runs
in
your
system.
It's
just
important
to
understand.
This
is
not
a
theoretical
problem.
We
see
that
about
1
in
7.
Packages
in
NPM
carries
a
known
vulnerability
in
there
in
its
own
code
or
in
one
of
the
dependencies
that
that
package
in
turn
uses.
So
it's
a
very
real
problem
and
most
of
your
applications
probably
have
use
of
some
of
these
vulnerable
components,
and
this
implies.
A
A
Leave
the
presentation-
and
we
will
see
we'll-
do
some
live
hacking,
though
oh
it's
fun
and
what
we'll
do
is
we
will
use
real
vulnerabilities
in
real
NPM
packages
and
understand
them,
exploit
them
a
little
bit
to
understand
their
impact
and
then
use
those
both
on
one
hand
as
awareness
to
the
potential
risks
that
might
come
in
that
NPM
package,
as
well
as
a
learning
vehicle
to
understand.
How
should
we
write
secure
code
ourselves
and
then
we
will
focus
on
node,
but
again,
this
sort
of
applies
to
client-side.
A
So
with
that,
let
me
move
over
here.
I'll
switch
to
the
browser
loaded.
Well,
ok!
So
this
is
a
JavaScript
talk.
So,
of
course,
I
have
to
do
MVC
application
in
it.
This
is
called
goof
and
it's
a
vulnerable
to
do
application.
It
is
vulnerable
by
virtue
of
pulling
in
some
of
these
vulnerable
packages,
and
it
allows
us
to
do
it's
a
to
do
application
right,
so
you
can
call
it
by
milk
or
you
can
say,
call
mom
or
all
sorts
of
reminders
for
you
to
do
and
goof
is
an
open-source
application.
A
It's
on
sneak,
slash,
goof
and
you
can
try
it.
So
what
we're
going
to
do
is
we're
going
to
test
it
and
see
which
vulnerable
packages
does
it
use
and
then
we'll
see
what
is
the
implication
of
it?
I'm
going
to
use
sneak
for
this
we'll
go
off,
choose
the
relevant
application,
so
over
here,
snake
would
have
tested
the
different
packages
that
I
have
or
different
repos
for
vulnerable
packages
and
I
will
choose
goof
and
see
that
I
have
a
bunch
of
these
vulnerable
packages
on
it
right.
A
So
this
is
sort
of
step,
one
just
to
understand
that
you
have
those
vulnerable
components
in
your
system
and
there's
a
bunch
of
them
here
and
I'm,
going
to
pick
a
few
that
I
have
sort
of
easy
exploits
to
show.
But
there's
a
bunch
of
these
vulnerabilities
they
can
read
up
on
including
a
fairly
recent
one
that
was
just
published
on
ejs
remote
code
execution
in
the
enterprise
in
the
EGS
templating
form.
A
So
we're
going
to
start
with
a
simple
export
here
on
SD,
so
SD
has
a
directory
traversal
vulnerability
and
typically
you
would
read
the
advisory
on
this.
But
you
don't
need
that
because
you
have
me
so
I
can
show
it
instead.
So
we
use
SD
in
our
application
to
serve
static
resources,
public
like
CSS
and
stylesheet
and
JavaScript
files,
as
well
as
to
show
kind
of
our
awesome
about
page,
which
is
just
sort
of
demonstrates.
How
awesome
goof
is
so
to
exploit
it.
A
We're
going
to
switch
to
the
command
line,
because
the
browser
is
just
not
sufficiently
friendly
for
a
hacking
activity
to
go
and
just
gonna
have
some
shortcuts.
For
me,
we're
just
going
to
go
off
and
we'll
do
a
bit
of
a
curl,
so
we'll
switch
to
sort
of
warm
up
and
get
our
about
page
via
curl.
So
far,
so
good
now
we
know
there's
a
directory
traversal
vulnerability.
A
So
when
you
have
that
when
attacker
would
watch
what
an
attacker
would
try
to
do
is
break
out
of
the
folder
where
the
static
resources
are
and
try
to
get
outside.
So
it's
going
to
try
to
do
something
like
this
and
if
you
do
that,
you
will
get
nothing
actually
you'll
see
that
you
got
redirected
to
the
goof
to
do
home
page,
and
the
reason
for
that
is
that
st
is
a
good
package
was
written
by
isaac
from
NPM
and
it
has
some
security
consciousness
in
it
and
it
did
try
to
avoid
the
specific
concern.
A
However,
it
has
a
vulnerability
and
that
vulnerability
is
in
not
factoring
in
all
the
different
encoding
paths
that
you
could
have
so
what's
another
way,
I
can
represent
a
dot
in
the
URL.
Anybody,
oh
sorry,
didn't
catch.
The
whole
thing
I
will
assume
that
you
said
URL
encoding,
although
I'm
not
sure.
A
If
that's
the
one
which
is
I
can
do
a
percent
tui
and
3%
to
80%
2e
%
to
e
and
I
can
just
go
back
as
much
as
I
want,
because
I
can
just
do
dot
dot
at
the
root
folder
as
much
as
I
want
and
then
say,
I
tacked
on
et
Cie,
passwd
and
voila
I've
got
DTC
passwd
file,
so
we're
just
getting
warmed
up.
This
is
a
very
simple
vulnerability,
but
just
sort
of
shows
it's
a
good
package.
A
It
has
secured
consciousness,
but
it
has
a
flaw
which
was
fixed
at
a
later
version
of
this
package,
so
getting
started
first
package.
You
know.
First
lesson
is
just
beware.
Encoding
second
package
we're
going
to
look
at
is
marked.
Who
here
has
heard
of
marked
okay,
a
good
number
of
hands?
It's
a
markdown
parsing
library,
and
we
use
it
in
goof
to
be
able
to
do
things
like
you
know,
emphasis
like
if
I
want
to
say,
buy
beer
and
I
want
to
give
it
a
sort
of
the
proper
attention
that
it
deserves.
A
Then
I
can
use
it
for
emphasis
as
a
variety
and
other
components
in
it
and
a
goof
uses.
Mark
then
marked
is
you
know,
it
gets
about
two
million
downloads
a
month
and
it
has
a
vulnerability
that
is
a
cross-site
scripting
vulnerability
and
how
it
processes
it.
So
it's
got
to
go
through
a
little
bit
and
understand
it
again.
Typically,
you
would
read
the
advisory
so
if
I
know
there's
a
cross
that
scripting
vulnerability
here.
A
What's
the
first
thing,
I
will
try
scrape
alert
one
/script
and
I
don't
get
anything
I
just
get
into
text
once
again
marked
has
a
security
controller
in
it,
unfortunately,
is
not
on
by
default
called
sanitize.
But
if
you
turn
on
sanitize
like
we
did
here,
it
would
capture
this
and
it's
really
comprehensive.
Even
if
I
went
ahead
and
I
did
something
like
this
and
said:
JavaScript
:
alert
1,
which
is
another
way
to
sort
of
embed
a
link.
It
would
still
catch
it.
A
A
No
not
as
well-known
as
a
as
a
your
own
encoding
is
HTML
encoding,
HTML
entities,
so
I
can
do
something
like
this
and
I
can
do
a
percent
41
I
think,
and
these
are
basically
just
equivalent
ways
to
represent
a
character,
ASCII
or
otherwise,
and
the
browser
would
interpret
them
the
same
way
toward
regular
code.
So
if
I
do
this,
sigh
still
catches
it.
So
it
really
is
a
very
comprehensive
and
sort
of
spec
compliant
type
of
defense
mechanism.
A
There
sanitization
function
and
marked
so
marked
was
actually
fine,
however
browsers
not
so
much
so
browsers,
say:
I
do
something
like
this
and
I.
Add
like
this
over
here
browsers
go
here
and
so.
Well,
you
know
I
see
the
ampersand.
They
see
the
hash
mark.
I
see
the
58.
You
didn't
go
all
the
way
and
kind
of
add
that
semicolon
there,
but
I
know
what
you
want.
You
know.
I've
got
your
back,
that's
okay!
This
is
a
call
it.
A
So
if
I
do
this,
if
Walla
suddenly
I
do
manage
to
get
through
it,
so
marked
was
actually
good.
You
know
they
sort
of
did
the
right
thing
and
they
are
very
spec
compliant,
but
the
browsers
with
their
flexibility,
and
just
like
this
complex
world
of
evaluating
pages
did
allow
that
to
do
it
and
we
got
server
script
into
it.
A
So
again,
both
examples
are
all
about
encoding
and
encoding
and
be
able
to
sort
of
circumvent.
Existing
sanitization
logic
is
a
very,
very
common
problem
in
NPM
packages,
any
node
code
as
a
whole,
and
it's
something
to
be
alert
of
kind
of
aware
of.
So
these
were
two
packages.
Let's
look
at
a
couple
more
and
then
we'll
kind
of
conclude
a
little
bit
more
and
we're
going
to
get
fancier
as
we
go
kind
of
get
a
little
bit
more
complex.
A
The
next
one
we
want
to
look
at
is
ms
who
here
has
heard
of
ms
okay
a
little
bit
less.
It's
actually
also
very
popular,
and
we
use
it.
It
is
a
package
that
converts
all
sorts
of
date
strings
to
to
the
number
of
milliseconds.
So
we
can
say
you
know,
call
mom
in
two
days
and
it
would
figure
out
that
the
two
days
means
so
many
milliseconds.
So
we
can
set
a
reminder
for
it,
so
it's
a
nice
little
package
very
widely
used
and
it
is
susceptible
to
a
regular,
regular
expression.
A
Denial
of
service
vulnerability,
so
here
is
probably
worth
stepping
back
a
moment
and
talking
about
the
event
loop.
So
one
of
JavaScript's
claim
to
fame
is
the
fact
that
it
runs
on
the
event
loop
and
it's
very
therefore,
naturally
scalable.
If
you
want
to
serve
many
clients,
you
don't
need
a
thread
per
client.
You
launch
one
thread
and
all
of
the
blocking
actions
all
of
the
I/o
functions
are
event-driven.
A
So
it's
just
a
tiny
bit
more
fragile
and
well,
we
don't
think
of
them
as
algorithms,
the
most
popular
algorithms
or
more
frequent
most
frequent
algorithm
that
we
run
in
our
code
is
a
regular
expression
and
actually,
let
me
go
back
a
little
bit
to
my
slides,
just
to
sort
of
explain
this
in
an
example.
So
regular
expressions
are
algorithms
and
they're,
really
a
state
machine.
They
run
through
a
string
and
they
typically
take
a
nonlinear
amount
of
time
to
process
input
nonlinear
to
the
length
of
the
input
that
they
got.
A
A
And
what
that
means
is
that
when
we
give
the
regular
expression
engine,
something
that
is
almost
there
that
almost
matches
a
regular
expressions
are
greedy,
they
really
they
aim
to
please
right,
then
they
would
run
through
it
and
they
would
get
all
the
way
to
the
end
just
to
realize
that
they
could
not
match,
and
then
they
would
backtrack
and
try.
Another
permutations
and
then
backtrack,
and
if
you
did
this
model,
you
would
trigger
what's
called
as
catastrophic
backtracking,
and
in
this
case
the
problem
is
that
this
C
letter
can
show
up
either
as
like.
A
Multiple
occurrences
can
show
up
as
the
plus
or
they
can
show
up
in
the
capture
group
there,
and
that
leads
to
many
many
many
different
permutations,
and
it
means
that
even
a
short
string
like
this,
this
is
thirtyish
strings,
may
take
a
second
to
process
and
every
character.
You
would
add
my
double
that
amount
of
time.
Clearly
this
is
on
a
computer,
but
you
know
it
would
take
down
threads
very
easily.
So
this
is
an
extreme
example
of
regular
expression.
A
So
we're
going
to
print
60,000
fives
as
the
raishin
of
time
and
that
would
again
sort
of
trigger
a
long
string
that
goes
into
into
that
regular
expression
and
the
other
thing
we're
going
to
do
is
we're
going
to
change
the
s
here
to
an
a
so
it
almost
matches.
It
gets
all
the
way
to
the
end,
but
doesn't
quite,
and
if
we
do
this,
it
takes
a
long
time
to
respond
and
in
the
meantime,
what's
maybe
more
interesting
is.
A
If
we
go
to
the
application
and
we
try
to
do
things
here-
nothing
happens,
it's
stuck
and
it's
because
the
thread
is
now
occupied
processing.
This
long,
regular
expression.
Now,
you
might
think
hey
60,000
characters
is
a
an
abnormal
length
of
input
and
you'd
be
right,
except
somebody
needs
to
actually
ask
that
question
and
block
the
long
input
coming
in
and
in
most
cases
that
doesn't
exist
and
unless
you
explicitly
put
that
in
there,
so
hopefully,
if
I
added
a
zero,
then
this
would
have
taken
basically
the
entire
length
of
the
presentation.
A
Hopefully,
this
is
now
done
and
the
pretend
the
system
cannot
run
again.
The
the
fourth
former
ability
and
the
last
one
I
want
to
show
is
in
Mongoose
who
here
is
heard
of
Mongoose,
probably
everybody.
Someone
goes
clearly
the
way
to
interact
with
MongoDB,
and
one
of
us
has
a
slightly
more
elaborate
vulnerability
triggered
by
buffer
buffer
is
a
tricky
object
in
the
world
of
node
that
you
might
have
heard
of,
and
the
reason
it's
tricky
is
that
it
deals
with
memory.
A
So,
if
I,
just
a
run
node
here,
I
was
assuming
of
it
even
more
buffer
supports
two
constructors.
So
I
can
do
a
constructor
that
says
buffer
new
buffer
100
with
a
string,
and
it
would
give
me
3
characters.
1,
0,
0
or
I
can
do
new
buffer
with
a
hundred
like
this,
and
it
would
allocate
a
hundred
bytes
and
that's
fine.
It's
a
little
bit
weird
that
you
can
pre
allocate
things
in
JavaScript.
A
So
it's
a
bit
of
a
unique
entity
in
the
server
JavaScript
world,
but
what's
more
interesting,
is
that
if
you
look
at
this,
you
see
that
every
time
I
allocate
the
memory
I
get
a
different
type
of
content.
That's
because
buffer
does
not
by
default
0.
The
memory
that
it
allocates
it
just
takes
up
whatever
chunk
of
memory
and
just
uses
up
those
100
bytes.
So
if
now
as
an
attacker,
if
I
can
leak
that
information
out
that
allocation
out
and
get
that
to
me
as
an
attacker,
I
have
remote
memory.
A
Exposure
I
suddenly
can
access
server-side
memory
and,
if
I
do
that
enough,
I
will
basically
expose
pretty
much
all
these
secrets.
That's
it
in
the
node
processes,
memory,
including
source
code
and
keys
and
the
likes.
This
is
what
happened
with
heartbleed
in
open
SSL.
This
is
remote
memory
exposure
so
because
buffer
is
so
tricky
because
the
constructor
is
like
this:
it
tripped
up
quite
a
few
packages,
Mongoose
being
one
of
them
and
we
use
we
use
buffer
as
a
part
of
our
database
schema
here
to
hold
our
content
entities.
A
So
what
we
need
to
do
is
we
need
to
somehow
trigger
the
allocation
of
the
use
of
the
integer
buffer
and
we're
going
to
do
that
using
a
technique
called
type
manipulation.
So
if
I
go
here
and
I
do
this,
what
we'll
do
is
we
will
switch
from
using
a
curl,
a
form
posting
to
another
type
of
input
that
our
application
supports,
which
is
JSON
very
popular,
very
prevalent
again
in
the
world
of
node
right
one
of
our
advantages.
We
could
take
JSON
as
input,
but
what
we
might
have
forgotten
is
the
new
JSON.
A
While
I
can
do
something
like
this
and
I
can
say,
oops
I
can
say,
content
800
like
this
and
I
will
get.
If
I
go
back
to
my
application
here
and
I
reload
I
will
get
a
string
800
with
the
JSON
relation.
I
can
also
do
this,
and
what
this
will
do
is
when
I
serialize
or
when,
when
this
object
gets
created
in
JavaScript.
This
would
now
have
a
type
integer
and
again,
unless
anybody
verified
it
in
the
process.
That
type
integer
would
now
be
passed
into,
that
buffer
would
be
stored
into
that
database.
A
And
now
that
record
holds
some
real-world
memory
and
I'm
just
going
to
get
some
binary
craft
here,
and
if
I
did
this
again
I'm
just
going
to
get
a
bunch
of
those,
and
sometimes
you
might
start
seeing
some
source
code
in
it,
but
it'll
be
a
different
chunk
of
memory
every
time.
So
this
is
a
remote
memory.
Exposure,
not
good.
You
know
very
problematic
again,
a
bunch
of
popular
packages
have
fell
for
it,
including
a
request
and
I
think
WS.
So
something
to
be
wary
of.
A
So
these
were
just
a
few
examples
of
vulnerabilities.
What
I
want
to
do
is
just
spend
the
last
couple
of
minutes
talking
about
remediation
right.
Hopefully
there
are
some
examples
here,
but
things
that
you
should
do
in
general
reminder
that
you
should
care
about
security.
When
you
write
note
code
and
some
specific
examples
of
things
you
can
take
care
of.
The
other
aspect
is
that
all
of
these
vulnerabilities
were
in
NPM
packages.
A
Goof,
actually
has
you
know
a
couple
of
vulnerabilities
in
its
own
code
with
most
of
the
vulnerabilities
in
it
are
from
NPM
packages,
seems
so
talking
a
little
bit
about
that.
The
way
that
you
would
address
that
is
first
test
for
it,
so
you
can
use
sneak.
You
can
use
whatever
tool
that
you
want
to
try
and
know
that
you're
using
a
vulnerable
package-
and
second,
is
you
want
to
fix
it?
The
way
that
we
do
it
and
in
snake?
A
Is
you
just
click
here
to
do
an
open
fix,
PR
which
would
prompt
you,
which
fixes
do
you
want
to
do
and
then
click
this,
and
it
will
generate
a
pull
request
with
the
necessary
changes
we
have
patches
for
some
of
these
vulnerabilities
and
we
have
guided
upgrades
to
various
others.
So
this
is
really,
with
the
intents
that
you
can
kind
of
build
this
in
to
your
workflow
and
make
it
a
natural
part
of
your
github,
workflow
or
or
CLI
workflow
or
whatever
workflow,
that
you
have
on
an
ongoing
basis.
A
And
then
you
want
to
make
sure
that
you
do
this
continuously
and
that
you,
once
you
are
vulnerability
free,
but
you
stay
that
way.
Right
that
you
don't
just
you
know
if
you
want
to
first
identify
the
problems
that
you
have
today
and
fix
them,
and
then
subsequently
you
want
to
do
that
in
a
continuous
fashion.
A
And
the
last
thing
you
want
is
you
want
to
be
set
up
to
be
able
to
get
alerts
or
be
reminded
about
new
vulnerabilities,
because
once
a
vulnerability
in
code
gets
disclosed,
it
is
now
known
to
the
attackers
as
well,
and
it
is
that
much
more
likely
to
be
exploited.
So
there's
a
bit
of
a
race
once
the
disclosure
occurs,
then
there's
this
race
that
kicks
in
to
say
you
know
who
do
the
defender
fix?
A
So,
to
recap,
back
to
my
slides,
first
of
all,
don't
go
start
hacking
websites
in
it.
It's
not
gonna
end
well
and
if
you
really
really
want
to,
you
can
go
to
a
github,
slash,
sneak,
slash,
goof
and
download
this
vulnerable
application
and
just
sort
of
have
at
it.
That
is
on
your
machine
and
you're
fine
with
it.
A
Hopefully,
this
talk
is
giving
you
some
takeaways
around
secure
coding.
So
you
know
just
to
recap:
what
we've
seen
is
encoding
is
tricky.
Think
about
all
the
different
encoding
paths
that
you
do
when
you
have
to
build.
It
be
careful
of
long
algorithm,
runs
and
specifically
for
regular
expressions,
try
to
contain
the
input
length
and
think
about
what
you
allow
in
and
just
when
you're
building
a
regular
expression
C,
you
know,
can
you
make
it
limited
in
length?
A
Beware
tide,
manipulation!
Type
manipulation
can
actually
happen
through
the
Q
s
package
through
various
other
aspects.
It's
a
little
bit
more
unique
to
scripting
languages,
it's
not
as
well
understood,
but
it
is
a
very
dangerous
type
of
attack
and
beware.
Buffer
buffer
does
have
in
the
newer
nodes.
There
is
a
buffer
dot,
Alex,
safe
and
buffer
dot.
A
lock,
unsafe
option
that
you
should
use
those
instead
of
the
default
constructor
and
in
the
different
packages,
and
unfortunately,
you
have
existing
code
that
uses
those
default
constructors.
A
You
could
choose
to
zero
the
buffers
as
a
command
line,
with
the
risk
of
breaking
some
functionality,
but
increasing
security.
I'll
kind
of
leave
that
decision
to
you
about
using
NPM
packages
I
would
encourage
you
to
find
those
vulnerabilities
be
aware
right,
get
the
head
at
his
hand.
You
know
accept
this
is
part
of
building
a
secure
equality
application
and
find
those
vulnerabilities
fix
them,
prevent
adding
new
vulnerable
packages
once
you've
done
that
and
then
respond
to
vulnerabilities
new
vulnerabilities
quickly,
a
lot
of
different
ways
to
do
it.
A
A
Come
and
and
I
have
I'll
take
some
questions
here
and
I'll
also
say
that,
because
we
like
to
say
that
snake
fixes
vulnerabilities
like
magic,
we
actually
have
magic
ones
that
a
hope
that
you
could
catch
in
it.
So
if
you
want
one
of
those
just
catch
me
after
the
talk
look,
if
you
won
any
questions,
I
think
we
can
do
a
couple
of
minutes.
A
Do
you
guys
do
any
auditing
of
private
packages
within
organizations
to
discover
vulnerabilities,
so
we
ourselves
Nick?
We
don't
do
like
we're,
not
a
services
company.
We
don't
do
auditing.
We
do
sort
of
recommend
that
you
get
a
security
consultant
to
do
that
for
your
code,
so
you
know
happy
to
chat
afterwards
about
specific
entities.
You're
talking
to
I
do
think
like
it's
very
important
to
secure
your
own
code.
A
That
said,
I
think
dynamics
are
changing,
and
today
the
majority
of
code
that
you
deploy
is
third-party
code
and
that's
also
the
easier
code
for
attackers
to
exploit,
because
you
know
they
have
access
to
it.
It's
just
dramatically
easier
and
that's
why
today
anywhere
between
80
and
95
percent
of
successful
exploits
happened
through
unpatched
known
components
like
unpatched
vulnerabilities,
and
you
know
it's
because
it's
the
low-hanging
fruit
so
hopefully
do
that
other
questions.