►
From YouTube: The State of Open Source Security - Liran Tal, Snyk
Description
Open source security affects everything from software supply chain attacks in package managers to container security which revealed in a recent study that the top ten most popular Docker images contain at least 30 vulnerable system libraries. In this session we will further explore the security posture of open source maintainers and deep characteristics of application dependencies across language ecosystems, with stories from the Node.js and npm ecosystem.
A
Good
morning,
everyone
thank
you
for
joining
me.
We're
gonna,
kick
it
off
with
the
state
of
open
source
security.
I
want
to
talk
to
you
about
high-level
view
of
everything
that
happens
on
language
based
software,
ecosystems,
containers
technologies,
projects
of
open-source
maintainer
Xen
developers
as
well.
So
quick
introduction
about
myself.
My
name
is
Liran
Tao
I'm,
a
developer
advocate
at
sneaked,
where
we
build
developer
friendly
security,
tooling
to
help
developers
build
secure
applications.
I'm
also
involved
with
the
no
js'
security
working
group
and
bunch
of
other
activities
across
a
wasp
and
publishing
books.
A
If
you
want
to
follow
me
on
twitter
and
ask
me
anything
about
us,
I'm
happy
to
help
and
I'll
be
here
the
whole
day
and
doing
the
collaborators
from
it.
So
you
know
just
find
me
around,
so
you
can
off
today,
I
think
nobody
would
question
the
fact
that
open-source
has
made
an
incredible
impact
on
modern
software
development
and
it
continues
to
expand.
A
The
use
of
open-source
is
accelerating,
however,
with
great
adoption
of
open
source
comes
great
responsibility
and
risk
that
we
need
to
mitigate.
You
know
whether
we
are
owners
of
open-source
maintainer
of
open-source
or
just
using
open
source
software
in
2018
vulnerabilities
for
NPM
grew
by
47%,
PHP
and
maven
had
grew
a
considerable
percentage
percentages
as
well
something
around
27
and
56
percent
respectively.
So
we're
seeing
all-in-all
about
88
percent
growth
of
application
security
vulnerabilities
in
the
last
two
years.
A
What
is
really
interesting
is
that
vulnerable
versions
have
a
long
tail
of
downloads.
In
other
words,
how
long
does
it
take
for
users
to
adapt
to
a
new
version
that
has
a
fix
from
an
old
one
that
is
vulnerable?
How
long
does
that
take?
So
we
turned
into
a
Python
the
pi
pi
registry,
and
they
took
a
look
at
a
pretty
popular
fairly
popular
package
called
WebSocket.
We
found
that,
even
though
it
has
a
high
denial
of
service
vulnerability
disclosed
in
August,
you
can
see
that
downloads
have
been
in
Oh.
A
Thousands
of
downloads
or
tens
of
thousands
of
downloads
have
been
actually
accumulating.
Even
after
that,
so
people
are
still
downloading
vulnerable
versions
of
that,
or
this
could
be
for
different
reasons.
You
know,
maybe
there's
a
no
legacy,
maybe
there's
issues
to
upgrade
you
to
a
fix,
but
considering
this
fact
you
know
we're
still
getting
those
long
tails
of
downloads
even
for
vulnerable
versions.
This
turn
is
actually
increasing
of
security
vulnerabilities
even
across
you
know,
well-known
system
libraries.
A
So
whether
you
look
at
things
like
you
know,
Red
Hat,
Enterprise,
Linux
Debian,
sees
all
of
those
UNIX
t-shirts.
Now
we're
seeing
those
same
trends
of
increasing
you
know:
CVS
and
security
vulnerabilities
being
reported
being
disclosed
and
we'll
get
to
that
in
a
bit,
but
I
will
say
that
you
know
those
TVs
that
we're
seeing
here
at
you
know:
Linux
OS
libraries
are
not
something
far
away
from
us.
Actually
they
manifest
in
the
container
technology
that
we're
using
you
know
most
probably
to
power
applications
and
bundle
them
with
them
so
kind
of
transit
transitively.
A
We
are
being
affected
and
impacted
by
these
vulnerabilities.
So
let's
take
a
look
at
what
happens
in
language
based
software
ecosystems,
and
how
much
do
we
rely
and
know
about
those
open
source
dependencies
that
we
use?
So
recent
academic
research
paper
had
actually
investigated
the
characteristics
and
properties
of
different
language
based
lacquer
systems.
It
took,
for
example,
Python
pi,
PI,
pi
PI
registry
and
also
NPM
try
to
compare
and
figure
out.
You
know
what
is
different.
What
is
familiar
and
similar
around
those?
A
What
it
found
out
for
in
pairs
specifically,
is
that
61%
of
all
packages
on
NPM
could
be
considered
abandoned
packages
now
straight
out.
That
seems,
you
know
very
outrageous.
You
know
proposition
to
say,
but
it
depends
what
do
you?
You
know
how?
What
is?
What
is
your
opinion
on
what
is
or
what
do
you
measure?
What
is
an
abandoned
package
right?
A
So
for
the
sake
of
this
research
paper-
and
you
know,
research
paper
being
you
know
something
easily
to
consume,
we
have
decided,
or
you
know
the
researchers
have
decided
that
an
abandoned
package
will
be
that
which
did
not
have
a
release
in
the
12
months.
So
rightfully
so
you
could
go
ahead
and
argue
back
that
you
know
last
12
months
did
not
have
released.
Maybe
that
package
had
reached
maturity.
You
know-
maybe
it's
already
so
well
known
and
well-developed.
It
does
not
need
anymore
new
releases.
Everything
is
fine
except
event.
A
Stream
incident
happened
a
security
issue
that
kind
of
I'm
pretty
sure
somewhere
up
to
some
people
in
the
room
have
heard
of.
If
not
your
whole
post
mortem,
you
will
not
have
a
problem
finding
and
googling
this
information,
but
just
like
put
it
into
into
like
a
small
disclaimer
of
what
was
going
under
event.
Stream
has
been
on
their
own.
A
The
NPM
registry,
for,
like
almost
eight
or
nine
years
since
then,
definitely
mature,
did
not
see
any
release
in
the
last
two
or
three
years,
but
someone
through
a
social
engineering
technique
was
able
to
go
ahead
over
over.
Take
publishing
access.
You
know
and
true
that
you
know
being
able
to
inject
a
malicious
package
inside
transitive
dependencies
of
event
stream
that
you
would
usually
also
probably
will
use
not
as
a
direct
one
but
as
a
transitive
dependency.
So
true,
all
of
that
injecting
something
into
a
package
that
being
downloaded
about
two
million
times
awake.
A
Another
interesting
insight
that
this
research
paper
pointed
out
was
that
if
you
take
a
look
at
what
you
install
your
average
NPM
install,
there's
a
whole
difference
between
what
happens
on
Python,
for
example,
to
NPM.
So
for
NPM
your
average
NPM
install
for
a
package
would
pull
in
full
levels
deep
of
nested
dependencies,
which
means
this
is
you
know
great
if
you're
like
tracking
something
like
Express
or
fast,
if
I,
but
at
at
the
same
time,
they're
gonna
pull
in.
A
You
know
a
bunch
of
those
other
dependencies
as
well
that
you
need
to
track
and
understand
as
well.
Have
this
the
exact
mindset
of
a
security
risk
of
what's
going
on
there
experimental
exercise.
Imagine
you
build
a
node.js
app.
Your
mental
image
of
the
application
is
this.
You
know
following
blob
where
you
see
you
know
your
application
being
deployed,
or
you
know
being
used
somewhere
except
the
reality,
however,
is
that
the
actual
code
that
you
write
write
the
code
that
we
write
as
developers
is
significantly
smaller
amount
than
what
we
actually
ship
out.
A
So
your
M,
your
mental
image
of
your
application,
might
be
a
bit
distorted
towards
the
reality
of
what
you
actually
wrote
versus
all
the
app
that
you
are
actually
responsible
for
as
well,
because
all
of
us
are
relying
on
open
source
software
community
powered
code,
which
is
you
know,
leveraging
beautiful
open-source
world
and
boost
our
productivity.
But
we
need
to
understand
this
concept
of
what
we
write
and
you
know
what
is
not
ours
and
then
what
is
our
risk
and
responsibility
towards
those
dependencies
as
well
so
granted?
A
It
is
I
think
hard
to
imagine
these
days.
Writing
software
delivering
products
without
being
reliant
on
any
kind
of
open
source
software
or
dependency,
and
you
know
managing
dependencies
for
project,
is
an
important
task
and
requires
due
diligence.
You
know
tracking
those
dependencies
that
you
use
and
that
you
rely
upon
and
making
sure
that
everything
is
ok.
A
A
Most
of
this
is
part
of
the
opens,
the
state
of
open
source
security,
or
that
we
published
in
which
we
have
taken
a
look
at
what
happens
both
for
users
of
sneek
and
the
ecosystem
itself,
etc,
and
what
we
found
for
this
example
is
78%
of
the
time
when
we
will
find
security
vulnerabilities
for
users,
you
know
using
snake
is
we
will
find
it
for
NPM
in
frontof
dependencies.
So
again,
going
back
to
that
example.
A
If
you
are,
you
know
a
JavaScript
or
noir
developer,
you're
tracking,
all
of
the
FASTA
file
change
logs,
all
of
the
angular
and
react
change,
logs,
etc.
Most
of
the
time
78%
of
those
when
we
find
security
vulnerabilities
for
your
project
as
we
scan
it
as
we
offer
you
fixes
for
it,
it
will
not
be
for
that.
They
reg
dependency
that
you
will
use.
It
will
actually
be
most
of
the
time
for
those
transitive
dependencies
you
can
see.
A
This
is
actually
a
bit
different
between
different
deco
system,
which
is,
you
know,
could
say
a
lot
about
what
is
going
on
with
oracle
systems,
but
I
will
not
go
into
that
right
now.
So
what
can
possibly
go
wrong
with
transitive
dependencies
in
my
applications?
So
I
have
a
whole
different
talk
about
what
is
happening
with
malicious
packages
on
ecosystems
and
I
won't
relate
in
to
one
one
of
them,
and
these
are
all
examples
and
use
cases
of
things
that
happened
in
security.
A
Incidents
that
happen
in
the
ecosystems
I'm,
going
to
really
into
something
that's
called
get
cookies,
get
cookies,
sounds
I,
guess
pretty
simple
in
terms
of
what
it
does
it.
Parses
HTTP
headers
for
cookie
data,
or
does
it
so
actually
get
cookies,
is
nothing
less
than
a
command
and
control
backdoor
the
sole
purpose
of
allowing
someone
to
attack
your
web
server
through
sending
command
injections
remotely
so
any
web
server
that
would
bundle.
This
dependency
will
actually
allow
a
malicious
attacker
remotely,
knowing
this
vulnerability
to
go
ahead
and
inject
any
kind
of
arbitrary
code
into
your
app.
A
How
does
it
does
so?
So
the
whole
kind
of
exploit
code
in
get
cookies
is
roughly
40
lines
of
code.
I've
actually
summed
up
the
important
part
here
to
process
this
remote
code
injection,
and
it
has
a
simple
switch
case-
does
three
things
reset
the
buffer
load
data
into
the
buffer,
which
in
our
case
will
be
JavaScript
code
and
then
execute
whatever
is
on
the
buffer?
So
someone
having
control
on
this
web
server
could
go
ahead.
You
know
input
inject
malicious,
JavaScript
code
through
things
like
HTTP
headers.
This
will
process
it.
A
You
know
reset
it
and
run
it
now.
The
attacker
had
to
build
a
whole
pyramid
of
nested
dependencies
to
hide,
get
cookies
behind
them
mind
you.
All
of
these
tree
dependencies
are
actually
offsprings
of
the
same
attacker
right.
All
of
them
belong
to
the
same
one,
but
one
or
two
or
three
malicious
packages
on
NPM.
Having
one
billion
packages
inside
will
not
you
know
be
that
much
of
a
threat
as
in
who
would
go
ahead
and
install
get
cookies,
which
has
maybe
zero
downloads.
A
So
without
a
vessel
to
propagate
this-
and
you
know
kind
of
claim
trust-
it's
gonna
be
hard.
So
what
this
attacker
was
able
to
do
is
compromised.
This
library
called
mail
parser,
which
has
something
like
half
a
million
downloads
on
the
on
the
you
know
on
the
registry
and
true
that
you
know
be
able
to
push
those
dependencies
into
the
metal
parser
project.
A
Now
male
parser
itself
is
not
a
web
server,
so
having
that
bundled
in
or
even
required
in
years
may
not
have
been
with
you
on
harm's
way,
but
perhaps
this
was
all
done
in
order
to
provide
some
legitimacy
in
terms
of
someone
searching
for
a
get
cookies
management
package
and
sees
something
gets
downloaded
half
a
million
times.
Well,
maybe
I'll
use
it.
A
So
this
kind
of
malicious
packages
happen
all
the
time.
Here's
an
example
from
the
NP
NGS
advisories.
We
could
find
that
also
as
like
a
sneak
volunteer.
Injuries
doesn't
really
matter
which
one
you're
tracking,
except
I,
wanted
to
give
you
the
fact
that
all
of
these
malicious
packages,
different
kind
of
type
of
squaring
attacks,
happen
all
the
time
right.
This
is
November
27.
This
is
just
like
two
weeks
ago.
A
How
do
we
handle
all
of
that?
How
do
we,
you
know
my
sure,
into
being
responsible
to
open-source
dependencies
to
what
do
we
install
for
the
sake
of
data
I've
created
a
project
while
back
called
npq?
What
it
does
is
when
you
do
an
ant
pick.
You
install
something
like
jQuery.
As
you
can
see
here.
This
is
a
wrong
abbreviation
of
jQuery,
because
this
is
actually
a
type
of
kwatak
package.
It
will
go
and
do
some
due
diligence.
It
will
check,
for
example,
how
much
or
is
this
package
is
it's
something
that
gets
20
download?
A
Is
it
just
new?
Someone
is
trying
to
maliciously
inject
users,
or
is
it
something
that
gets
downloaded
a
million
times
times
a
month
to
probably
get
some
kind
of
trust
from
the
community
around
it?
Does
it
have
a
repository
open
source
repository
associated
with
it
to
allow
you
to
go
ahead,
you
know
and
and
ensure
that
there's
like
an
open
source
code
base
that
you
can
in
check,
etc.
Maybe
it
has
wonder,
abilities
in
it.
Why
would
you
not
know
about
it
before
installing
it?
A
You
know,
rather
than
after
the
fact
and
then
finding
out
ways
to
mitigate
it?
So
here's
one
example
that
we
can
go
ahead
and
use
to
be
a
bit
more
responsible
and
security
vulnerabilities
happen
all
the
time.
What
are
you
using
you
know?
Different
types
of
language
ecosystems
here
is
marked,
for
example,
a
very
popular
markdown,
parsing
library
for
node
and
JavaScript
kind
of
used
between
the
server
and
the
front-end
as
well.
You
can
see
that
there's
a
fix
for
it
for,
like
a
reduce
vulnerabilities
happen.
A
You
know
just
awhile
back
right
just
few
months
back
and
the
interesting
thing
about
vulnerability
is
at
least
in
the
last
two
years
is
that
they
have
a
bit
shifted
in
terms
of
the
trend
that
we're
looking
at.
So
when
2016
as
we
look
at
you
know,
the
high
and
medium
have
like
a
kind
of
ratio
where
there's
more
a
medium
than
high.
In
the
last
two
years,
we've
seen
this
ratio
actually
flip.
A
So
more
of
this
vulnerability
that
we're
seeing
actually
high
than
medium
so
multiple
uppers
and
maintainers
I
think
would
agree
that
security
should
play
an
important
role
when
we're
building
our
applications,
except
there
are
no
text
books
and
how
do
you
build
secure
applications,
or
so
many
guidelines
and
os
kind
of
like
standards
or
like
semi
standards,
but
there's
no
like
open-source
maintainer
in
this
room.
That
would
you
know,
say
I'm
following
this
and
that
standard-
and
this
is
how
I
do
secure
code
so
standard
can
also
vary
between
different
projects,
which
means
you
know.
A
One
project
can
follow
very
good
and
highly
secure
guidelines
and
secure
coding,
conventions,
etc.
But
another
open
source
project
know
very
very
you
know
popular
in
the
same
in
the
same
sense
would
not
follow
those
as
well
so
of
these
security
standards.
Things
for
open-source
project
is
very
varied
in
terms
of
how
it
is
done.
So
just
in
this
year's
2019
state
of
the
october's
report
from
github
security
was
actually
the
most
popular
project
integration
app
category
and
the
more
we
use
open
source
software
I
think
that
we
realized
this
research.
A
So
truly
a
survey.
We
asked
some
questions
for
maintainers
and
developers.
In
this
part,
we
asked
open
source
materials
to
write
their
security
knowledge
and
how
good
that
is.
So
we
found
that
70%
of
open-source
maintainer
would
actually
not
feel
that
confident
in
handling
a
security
issue
if
it
was
disclosed
to
them
so
averaging
their
security
knowledge
somewhere
around
six
point
six
out
of
ten.
A
Moreover,
as
much
of
you
know,
we're
seeing
adoption
of
CI
tools,
whether
that's
like
things
like
circle,
CI,
for
example,
to
help
us-
you
know,
you
know-
have
a
have
a
good
CI
CD,
a
kind
of
pipeline
thing.
They
still
go
underutilized,
so
you
know
we're
not
enabling
you
know
we're
not
empowering
that
the
CI
integration
that
we
have
for
applications,
this
devops
pipeline
to
go
ahead
and
put
security
into
it.
A
As
a
testament
of
that,
you
know
when
we
asked
developers,
you
know
how
often
or
what
is
the
currents
of
like
the
security
auditing,
one
of
four
open
source
main
tenets
not
perform
any
source,
any
sort
of
security
auditing
for
their
projects,
so
security
practices
are
taking
many
different,
shapes
and
forms,
and
some
of
which
are
really
easy.
Winds,
for
example,
choosing
a
really
good
password.
So
your
package
would
not
get
compromised
right,
like
mail
processor,
like
many
other
packages
and
incidents
that
were
happening
before
on
the
ecosystem.
A
A
So
its
responsibility
of
all
of
us,
enabling
2fa
making
that
possible
for
us
making
the
security
possible
for
users
consuming
open-source
software
interesting
take
is
how
does
this
affect,
and
how
does
this
look
like
an
adjustment
ecosystems,
for
example?
What's
the
state
of
open
source
of
2fa,
for
example,
in
in
docker
hub
as
an
ecosystem?
Well,
funny
thing
is
it's
zero
percent
and
there's
a
whole
funny
story
around
it
and
that's
kind
of
accurate
to
October
1st,
which
I'll
get
to
in
in
a
minute?
And
why
does
that
happen?
A
Because,
somewhere
around
June
someone
on
the
docker
repository
chimed
in
on
this
issue
and
said
you
know
we're
planning
to
rolling
out
this
multi-factor
authentication
at
the
end
of
June.
Everyone
we're
thumbs
up
great
amazing.
Let's
do
it
except
it
didn't
happen,
someone
chanting,
Angela
and
say
you
know:
hey
we're
July!
What's
up,
you
said
June
and
then
came
August.
You
know
someone
chimed
in
again
and
said.
You
know
this
is
August.
What's
going
on
fellas?
How
are
we
doing
there
I
like
it
that
they
are
giving
the
programmers
kind
of
perspective
into
it?
A
I'm
a
programmer
myself?
How
hard
can
it
be
all
right?
So
we
didn't
have
it
back
in
in
July
back
in
August
guess
what
happened
in
September?
Nothing
much!
We
didn't
not
have
2fa
available
they're,
reminding
you
that
we're
talking
about
docker
hub.
This
is
a
very
primary
registry
for
docker
container,
probably
powering
a
lot
of
applications
for
everyone
in
this
room,
including
myself,
an
October
coming
up
right.
What
are
we
what
is
happening
there?
So
there's
an
interesting
update.
A
A
Here
is
a
pull
request.
I
opened
on
github,
but
you
can
see
that
I
have
actually
part
of
this
pull
request
for
a
real
project,
actually
changed
some
dependencies
as
I
needed
to
what's
part
of
my
contribution
can
see
that
my
yarn
log
file
is
actually
not
being
displayed
because
we
take
that
kind
of
for
granted.
It's
a
machine
generated
thing.
Is
there
anything
that
I
need
to
look
at?
Maybe
not.
You
know,
there's
a
whole
lot
of
code
being
changed
as
well.
A
So
it's
kind
of
collapsed
and
you
know
do
not
show
you
all
of
that
and
if
I
will
open
it
up
and
show
you
what
were
my
contributions
along
this
dependency
update
along
the
code
that
I
actually
added
as
well.
Maybe
the
those
of
you
will
with
a
good
eyesight
here
will
actually
see
that
on
the
left,
I'm
actually
changing
something.
A
That
is
an
actual
package
that
is
being
used
from
the
registry,
and
you
can
see
on
the
right
that
my
change
is
actually
using
the
exact
same
package
but
from
my
own
controlled
domain,
whether
that's
like
a
an
NPM
proxy
mirror
or
I,
can
already
install
it
directly
as
you
can
install
NPM
packages
from
github
and
it
has
malicious
code
in
it.
So,
as
you
will
merge,
this
pull
request,
we'll
probably
not
see
it
because
you
know
you
did
not
even
take
care
of
go
ahead
and
you
know
reviewing.
A
What's
you
know
in
a
locked
file?
Go
ahead,
merge
it
maybe
you're
at
this
point
when
you're
doing
an
NPM
install
the
next
time
any
of
those
developers.
We
usually
know
enough
look,
probably
usually
being
used
for
application
developers
of
a
project,
specifically
not
the
consumers
of
it.
You
might
be
susceptible
to
this
injection
attack.
So
why
don't
we
have
tools
to
help
us
with
it's
very
simple
things.
There
we
go
I
built
this
thing
called
lock,
file,
lint,
I,
think
as
JavaScript
developers,
we
heavily
rely
on
static
analysis
and
linters.
A
So
there
we
go
another
one
that
you
can
add
to
your
CI
lock
file,
and
you
can
tell
it
to
validate
that
everything
is
first
of
all
HTTPS
specific
sources.
What
are
you
using?
You
know
just
NPM
or
just
yarn.
You
don't
want
anyone
to
inject
anything
from
github
or
anything
other
I
like
that
there
we
go
another
tool
that
you
can
go
ahead
and
use
in
your
CI.
A
Perhaps
a
silver
lining
in
in
most
of
this
talk,
I
would
say
you
know
we're
not
doing
that
bad,
but
across
the
ecosystem,
but
I
would
say
what
is
the
silver
lining
here?
As
we
ask
the
velop
resume
turns
you
know
who
is?
There
is
Swiss
like
actually
responsible
for
security,
and
the
most
of
the
respondents
have
been
around
developers,
and
this
is
great
because
we're
seeing
this,
you
know
strong
statement.
You
know
strong
testament
of
developers
being
like
fools
back
and
it's
not
just
owning.
A
You
know
the
DevOps
or
the
back
end
in
the
front
end.
It's
also
being
you
know
responsible
for
things
like
performance
or
applications,
accessibility
requirements,
how
about
security
for
applications
as
well,
understanding
the
risk
of
for
us
as
maintenance
of
open
source
software
to
actually
like
mitigate
and
and
push
out
security
fixes
is
really
really
important
in
terms
of
how
are
we
actually
rolling
this
out
so
I
want
to
show
you
an
example
happened
not
a
whole
long
time
ago.
A
This
is
a
github
project,
for
a
very
popular
NPM
package
doesn't
remember,
doesn't
matter
the
name,
because
these
kind
of
things
happen
all
the
time
but
I'm
giving
you
one
example
where
someone
was
chiming
gaining
saying:
oh
there's,
a
vulnerability
that
was
reported
are
there's
a
link
to
the
speak
phone.
You
know
telling
the
person
to
go
ahead
and
release
like
the
owner
of
this
package
to
go
ahead
and
release
like
a
new
version,
so
this
can
be
consumed
as
a
fix
for
for
the
package
that
they
are
relying
upon
at
the
transitive
DEP.
A
That
has
a
vulnerability
in
it.
The
meter
did
get
involved
right.
This
did
happen.
You
know
everyone
were
proactive
about
doing
it,
except
you
know,
I,
think
kind
of
like
lack
of
education,
of
how
you
mitigate
security
issues.
It
was
published
at
a
major
version,
so
if
version
2
is
vulnerable
and
you
publish
as
a
maintainer
affixed
in
version
3,
that's
gonna
be
a
bit
tricky
because
being
having
an
automated
upgrade
from
2
to
3
has
different
semantic
meanings
to
it.
Maybe
an
API
was
broken.
A
Maybe
you
know
I
see
a
very
elaborate
C
I
will
not
go
ahead
and
update
it,
because
they
are
afraid
that
this
will
break
their
applications.
So
there's
a
whole
lot
of
you
know
a
security
education,
not
in
terms
of
how
you
write
secure
code,
but
also
how
do
you
push
that?
How
do
you
make
that
available
to
users
to
consume
it
in
a
very
seamless
way
that
you
know
automated
upgrades
things
like
you
know,
dependable
or
sneak
upgrade
PRS
would
be
able
to
go
ahead
and
pull
in
those
new
versions
for
you.
A
So
there's
a
whole
lot
of
best
practices
for
open-source
maintainer
I've
got
this
cheat
sheet.
Some
of
it
is
kind
of
left
here
you
can
find
it
online
as
well.
I've
worked
on
that
with
Juan
de
kado,
who
is
the
maintainer
over
that
sure
local
NPM
proxy?
It's
been
doing
an
amazing
job
as
well
for
open
source,
so
moving
on
what
about
open
source
dependence
is
impacting
container
security
technology?
A
What
is
this
increased
of
adoption
I
think
around
docker,
and
you
know
the
strong
wrote
of
around
open
source
that
we're
saying
and
is
expected
to
grow
more
and
more
we're
talking
about
more
than
1
billion
downloads
happening,
probably
every
one
or
two
weeks
on
the
container
registry
docker
hub
reported
about
1
million
applications
in
the
form
of
container
images
being
uploaded
to
the
registry
in
the
last
in
the
docker
hub
registry,
I
should
say
in
the
last
year.
So
this
is
you
know
very,
very
much.
A
Fueling
or
open
source
wrote
accept
docker
images,
you
know
almost
always
bring
known
vulnerabilities
alongside
a
great
value.
So
if
we
take
a
look
at,
you
know
just
counting
those
10,
most
popular
docker
images
on
docker
hub.
Just
you
know
scanning
that
most
popular
page
of
all
of
those
images.
We
would
find
that
if
you
just
get
a
default
images
of
each
of
them,
they
at
least
have
each
30
vulnerabilities
inside
them
notice.
A
You
know,
presumably
are
here
with
580
as
well,
so
most
of
those
vulnerabilities
are
actually
recognized
from
the
base
image
or
your
application.
So
this
is
why
it
is
so
crucial
to
understand
you
know
what
are
you
using
as
a
base
or
as
a
perfect
image
in
your
docker
file,
if
you're
using
something
like
debian
jesse,
you're
gonna
pull
in
something
like
seven
hundred
dependencies,
if
you're
using
something
like
buster
or
justice
liam
or
some
other
variations
of
it,
I'm
gonna
pull
smaller
images.
A
You
know
smaller
dependencies
of
always
libraries
inside
them
and
thus
also
I'm
gonna,
pull
in
lesser
honorable
owner
abilities
as
well.
That's
a
smaller
image
and
the
thing
is
that
fixing
it
can
be
really
easy.
So
if
you
understand,
if
you
know
this
fact,
you
know
you
you
understand
that
fixing.
It
is
something
that
is
very
easy
to
do.
For
example,
44%
of
those
darker
image
vulnerabilities
can
just
be
you
know
fixed
if
you
change
too
on
your
image.
A
A
Just
by
using
you
know,
just
by
using
that
you're
vulnerable
to
this
amount
of
vulnerabilities
now
sure
granted
may
know
you
may
not
all
be
exploitable,
they
may
not
have
all
exploit
in
the
wild,
but
why
would
you
ship,
by
default,
almost
600
vulnerabilities
with
your
doctor
application,
there's
no
sane
way
or
sane
reason
to
do
that?
Use
a
different
image
except
I
know.
It
is
not
that
you
know
it's
a
bit
of
a
smarty
kind
of
way
from
it'll
just
go
ahead
and
say
it,
but
we
need
a
tool
to
help
us
do
this.
A
A
The
only
the
other
thing
that
we
should
kind
of
like
pay
attention
to
is
that,
just
by
rebuilding
an
image
we
can,
we
can
go
ahead
and
mitigate
20%
of
the
darker
image
vulnerabilities,
because
rebuilding
an
image
may
pull
it
depending
on
how
the
image
is
built.
You
know
when
you
opt
get
updates
or
new
upgrades
coming
in
and
pulling
in
your
versions
if
nothing
is
have
been
pinned
by
the
dependency
manager
inside
the
OS
itself.
So
we're
talking
a
lot
about
container
technology.
You
know.
We
also
ask
some
people
some
questions
about
this.
A
So
when
do
you
scan
your
daughter
images
right
for
OS
vulnerabilities?
Interestingly,
even
though
security
is
such
an
important
part,
even
though
there's
a
whole
train
of
security,
CVS
going
on
and
we're
not
so
as
50%
of
developers
will
fail
to
do
so,
they
will
not
scan
those
dependencies.
Even
it
is
something
that
it's
very
easy
to
do.
Many
tooling
available
free
and
some
of
them
are
open
source
as
well.
You
can
go
ahead
and
and
check
that
what
about
you
have
those
containers
deploy
to
production?
A
What
about
going
ahead
and
testing
this
on
production,
because,
unlike
functions,
which
are
very
short-lived,
boqueria
docker
containers
could
be
very
long-lived.
You
could
have
a
very
legacy
service
or
micro
service
that
the
team
is
using,
has
been
deployed
to
production.
No,
no
one
had
pushed
any
update
on
to
it.
It's
been
running
for
like
a
month
or
two.
It
is
now
in
production.
Maybe
there
are
new
civvies
affecting
it,
something
like
a
new
heartbleed
or
whatever
that
could
be
impacting
it
still.
A
50%
almost
50%
of
developers
or
engineers
would
not
even
find
out
about
it.
So
I
guess
another
silver
lining
for
container
technology
is
that
developers
are
still
even
for
that.
For
the
sake
of
docker
images
and
docker
father
stuff,
like
that,
you
know
with
the
empowerment,
I
think
of
developers
to
kind
of
own
their
infrastructure
as
well
we're
seeing
a
good
I
think
it
good
and
positive
trend
in
terms
of
you
know
us,
as
developers
owning
the
security
of
our
container
technology
as
well.
A
So
some
best
practices
around
docker
image
security
are
that
you
can
find
or
the
whole
kind
of
linters
and
how
to
scan
them,
and
you
know
very
easy
things
that
you
can
go
ahead
and
pull
into
your
pipeline.
It's
you
can
go
ahead
and,
like
ping
me
afterwards,
I'll
give
you
all
the
links,
and
all
this
will
be
available
after
the
talk
as
well,
but
I
would
I
would
want
to
end
off
with
with
kind
of
like
this
note
or
attackers
are
kind
of
kind
of
targeting
open
source,
because
you
know
finding
one
vulnerability.
A
One
CV
affecting
you
know
fast
if
I
annular,
whatever
kind
of
open
source
project
that
you
may
use,
is
also
kind
of
translates
into
many
victims,
because
there's
always
a
lot
of
users
for
these
open
source
packages.
So,
if
something
has
you
know
very
large
popularity,
it
means
they'll,
probably
be
able
to
infect,
or
you
know,
attack
a
lot
of
consumers
as
well
as
not
everyone
may
be
up
to
date.
A
What
if
it
was
something
that
you
would
just
push
into
your
CI
example,
showing
sneak
what
you
can
use
and
p.m.
audit
or
us
dependency
checks
in
your
CI
tooling
as
well,
but
what
a
fee
would
have
this
security
integrated
into
your
pipeline
into
your
workflow?
So
when
someone
adds
a
new
vulnerable
package,
when
someone
adds
you
know
a
new
security
vulnerability
to
a
transitive
package,
your
CI
breaks
right,
you're
a
bit
more
conscious
in
how
to
do
this
in
a
more
significantly
considerable
way,
a
more
responsible
way
to
protect
your
open
source
dependencies.
A
Good
question:
I'm
not
sure
we
are
defining
a
specific
echo
system
like
NPM.
If
that's
what
you
mean
as
polluted
as
in
Java
would
have
you
know
a
similar
amount
of
depend
of
like
open
source
vulnerabilities
growth
and
in
a
similar
kind
of
it's
not
like
a
like
an
order
of
magnitude
difference,
it's
kind
of
the
same
playing
field
as
well.
It
is
more
about
I,
think,
understanding
the
security
risk
and
being
able
to
do
something
about
them.
Understanding.
A
You
know
what
you
should
be
responsible
for
not
taking
those
things
for
granted,
so
I,
don't
think
like
a
specific
industry
is
polluted
or
not,
there's
a
whole.
If
you
go
and
dive
into
the
report
itself,
you
would
see
that
we
actually
looked
into
kind
of
very
early
stage
growth
ecosystems
like
a
goal
that
would
have
you
know
they.
A
They
also
have
kind
of
like
this
trend
of
increasing
vulnerabilities
and
even
though
it
has
like
a
whole
significant
amount
of
secret
owner
bills
in
total
compared
to
something
else,
but
you
could
attribute
that
to
you
know,
maybe
go
isn't
that
popularly
used,
maybe
security,
researchers
simply
not
looking
at
it
to
go
ahead
and
find
vulnerabilities
there.
So
this
whole
kind
of
wide
range
of
what
would
be
the
reasons
that
we're
not
saying
this
in
go
overseas.
You
know
NPM
or
Java,
for
example.
A
B
A
B
A
Sure
so
glad
you
were
bringing
this
up.
So
actually,
this
security
researcher
who
found
this
his
name
is
daniel.
Bruhl
is
actually
involved
with
radicchio
and
a
bunch
of
other
projects.
His
a
ver
security
minded
developer
as
well
he's
not
a
security
researcher
by
profession
and
what
he
discovered
is,
if
you're
using
NPM
or
yarn
they
they
both
so
the
NPM
kind
of
like
not
the
ecosystem
itself.
A
What
like
the
the
tooling
around
it
allows
you
to
distribute
binary
files,
so
you
could
go
ahead
and
you
know
by
the
way
that
I
was
building
this
and
pick
you
and
lock
for
a
link,
see
allies.
You
could
go
and
build
in
a
CLI
where
you
install
something
make
it
global,
NPM
or
you're
on
as
a
client
will
go
ahead
and
make
you
know,
make
the
whole
path
and
seam
links
changes
so
anywhere
in
your
in
your
shell
kind
of
prompting.
You
would
go
ahead
and
be
able
to
run
commands.
A
The
thing
that
Daniel
found
is
that
you
could
have
he
called
it
like.
We
call
that
terminology
is
like
a
beam
planting.
The
idea
is
that,
if
say
one
one,
one
NPM
dependency
we
can
take
in
whatever
example,
you
want
with
one
define
the
specific
bin
file
to
be
executed
like
a
CLI
and
installs
it,
and
there
is
a
turn
and
then
there's
like
another
one
like
T,
that
you
install
so
I
can
different
package
that
you
install,
but
it
uses
the
same
kind
of
name
for
that
bin
CLI.
A
It
will
overwrite
the
original
one
that
was
created
before
that.
So
you
could
actually
say
you
know,
for
example,
if
you're
using
young
man,
which
and
I'm
gonna
go
completely
a
hardcore,
retro
old-school
kind
of
thing,
using
yeoman
as
a
CLI
I
could
go
ahead
and
create
this
yo
man.
Whatever
get
you
to
install
it
once
you
installed,
it,
I
will
actually
be
able
to
overwrite
the
original
yo
command
Y.
Oh,
that
yeoman
had
actually
declared
I'm
actually
being
able
to
override
something
else.
It
is.
A
You
could
say
that
you
could
do
the
same
thing
with
script.
So,
basically,
when
you
install
something,
you
could
just
go
ahead
and
do
like
a
post
install
scripts
and
do
the
exact
same
thing
except
NPM,
and
you
are:
has
this
ignore
scripts,
which
is
a
convention
at
you
know,
security
con?
You
should
probably
understand
in
years,
but
even
if
that
is
used,
this
kind
of
blimp
and
been
planting
could
still
happen.
So
it
is
still
a
very
significant
security
issue.
A
The
only
way
to
kind
of
like
become
vulnerable
to
that
is
if
dependency
is
being
installed,
and
you
know
declaring
those
those
been
files,
which
is
something
that
you
know
could
happen
if
you
install
it
like
specifically
like
at
BMS
or
something
or
maybe
that
gets
installed
as
the
transitive
dependency
as
well.
So
you
know,
don't
have
a
lot
of
control
on
what
what
gets
there.
B
A
I,
don't
think
there
have
been
none
as
we've
seen
it's
a
fairly
new
issue,
Daniel
actually
consulted
with
me
about
it.
We
talked
to
its
NIC
security
team.
We
involved
both
NPM
security
team
as
well
as
yarn
mile
is
the
current
maintainer
for
yarn.
Actually
contact
contacted
all
of
them
kind
of
to
consolidate
all
of
this
messaging
and
communications
and
have
all
been
like
NPM.
Anyone
have
been
releasing
a
security
updates,
so
we
haven't.
This
is
like
freshly
used
for
like
the
last
four
days
or
something.
A
Yep,
it
is,
you
know,
I
graphed,
that
as
well,
it's
basically
this
one
ticket
shooters
like
also
golang
and
others.
What
is
it
yeah
yeah?
That
was
just
in
pain,
specific
hard,
I,
remember
that
was
the
one
yeah
this
one
for
eco
system
considers
groped
for
everything
goal
and
as
well.
It's
all
kind
of
growth,
I.
A
A
So,
first
of
all
for
NPM
and
JavaScript,
we
have
been
having
a
lot
of
activity
around
that
so
that
the
security
working
group,
being
there
you
know,
being
a
bit
more
active
and
vigilant
and
what's
going
on
assigning
city,
is
so
there's
there's
also
been
like
a
lot
of
activity
so
obviously
like
there
will
be
more
CVS
as
well,
if
no
one
had
looked
at
it
before
so
that
contributes
the
other.
The
other
thing
is
not
everything.
Is
you
know
exploitable?
A
So
you
have
you
know
you
may
be
vulnerable
to
like
some
high
issues
but,
for
example,
just
may
have
a
reduced
attack
versus
whatever,
but
you
need
to
understand
that
you
know
just
is
maybe
a
dev
dependence
you're
not
deploying
that
to
production.
So
that
is
not
something
you
know
specifically
to
like
worry
about
right
under
a
kind
of
like
a
statement
here,
so
there's
a
whole
kind
of
like
prioritization
understanding.
You
know
what
is
an
actual
risk.
You
know
what
is
a
manifested
risk
and
what
is
something
that
may
not
impact
you.