►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Keynote: Hacking the OSS Supply Chain - Melissa McKay, Developer Advocate, JFrog
JW Grand Ballroom 7 - 8
Speakers: Melissa McKay
Developers depend upon an ecosystem of open-source technologies that fuel innovation and decrease time to market. A typical business application is composed of 80% open source code, so what happens when the open source software supply chain gets hacked and thousands of enterprises are left exposed to potentially devastating security exploits. The SolarWinds hack is just the tip of the iceberg on a much larger security concern that spans the industry affecting all programming languages, platforms, and cloud services. In this keynote we will expose security holes and exploits in the open source ecosystem as well as propose a system for securing the software supply chain at a fundamental level.
A
Hello,
everyone
excellent
time
to
be
here
in
hot
texas.
This
is
my
first
time
here
in
austin,
so
really
privileged
and
happy
to
be
here
to
talk
with
all
of
you
about
hacking,
the
oss
supply
chain.
Now
I
only
have
a
few
minutes,
so
I'm
going
to
go
through
this
pretty
quickly
a
lot
of
what
I'm
going
to
talk
about
today,
just
amplifies
what
you
heard
from
brian.
So
I
want
to
take
a
lot
of
this
as
a
call
to
action
to
you
and
we'll
talk
about
that
a
little
bit
at
the
end
here.
A
First,
I'm
going
to
breeze
through
some
of
the
most
famous
hacks
that
have
happened
that
were
all
over
the
media
caused
a
bunch
of
issues.
You
heard
brian
talk
about
equifax.
This
was
apache
struts.
This
was
a
known
vulnerability.
We
knew
about
it,
didn't
get
it
updated
in
time
and
caused
all
kinds
of
problems.
Actually,
some
statistics
on
that
1.4
billion
in
cleanup
costs,
1.38
billion
in
consumer
claims-
that
was
143
million
customers
pretty
big
deal
next.
Solar
winds.
We're
tired
of
hearing
about
this
one.
I
kind
of
feel
bad
for
this
company.
A
Like
brian
said,
you
know
it's
not
fair,
sometimes
when
this
happens
but
you've
got
to
watch.
You
know
your
supply
chain,
and
this
is
what
happened
with
solarwinds
someone
got
into
their
team
city
server
and
replaced
a
binary
after
it
had
already
been
built,
and
you
know,
ran
amok
with
that
log
for
shell
again
another
one.
This
was
terrifying
for
all
of
us
java
developers.
All
of
us
use
this
code
just
about
every
single
system
that
runs
any
java
process
had
to
be
updated
because
of
this.
A
So
all
of
these
things
scare
us
terrify
us,
but
it's
just
the
tip
of
the
iceberg,
and
it
really
has
to
do
with
paying
attention
to
where
our
dependencies
come
from.
Now
I've
been
a
developer
for
over
20
years,
so
I
know
how
this
works,
especially
when
you're
a
junior
you
sit
down.
You
start
working
on
a
project,
you're
excited
to
get
something
up
and
running.
The
first
thing
you
do
is
build
your
code.
A
Well,
where
does
that
come
from?
Where
does
this
stuff
you're
working
with
come
from?
Most
developers?
Work
smarter,
not
harder.
So
we're
going
to
take
advantage
of
all
of
the
open
source
projects
and
libraries
out
there
for
us
to
use.
We
don't
like
to
reinvent
the
wheel
if
we
don't
have
to
it's,
not
efficient
and
or
economical
for
anywhere
we
work.
So
this
is
what
we
do.
We
go
to
public
repositories
and
we
collect
these
libraries
that
our
applications
depend
on
and
that's
it.
A
Who
do
you
trust
we
forget
to
carefully
consider
where
these
dependencies
are
coming
from
and
a
lot
of
the
default
behavior
of
our
package
managers?
So
I'm
a
java
programmer,
I
use
maven
central
all
the
time
this
by
default.
Is
you
know
this
is
what
maven
does
if
you
don't
specify
a
different
repository,
you're
going
to
be
pulling
things
from
maven
central
same
with
npm
same
with
pi
pi?
These
are
all
public
registries
and
I'm
not
saying
they're
a
bad
thing,
I'm
just
saying
that
they
have
their
purpose,
there's
a
reason
they're
there.
A
This
is
how
we
share
our
libraries,
especially
our
open
source
ones.
This
is
where
we
make
our
libraries
publicly
available
for
the
rest
of
the
developer
community
they're
important,
and
we
need
to
keep
them,
but
we
also
need
to
verify
what
we're
getting
just
like
when
you
go
to
the
grocery
store,
and
you
pick
up,
you
know
a
container
of
yogurt
check
the
date
before
you
leave
the
store,
make
sure
that
you
know
something
isn't
expired.
This
would
be
the
same
thing.
We
need
to
do
with
our
registries.
A
Okay,
we
need
to
get
serious
about
open
source
security,
so
every
time
you
do
any
of
these
commands,
you
do
a
pip
and
install
a
go,
get
a
maven
fetch.
What
dan
lawrence
said
this
quote
is
attributed
to
him
you're
doing
the
equivalent
of
plugging
a
thumb,
drive
you
found
on
the
sidewalk
and
to
your
production
servers.
A
Now,
there's
some
history
behind
this
in
2011,
the
department
of
homeland
security
ran
a
test
to
see
just
how
easy
it
would
be
to
get
workers
to
infect
their
own
computer
systems
and
staff
secretly
dropped
computer
disks.
This
was
a
while
ago
and
usb
thumb
drives
in
the
parking
lots
of
government
buildings
and
private
contractors
and
of
those
that
were
curious.
Now,
how
many
of
you,
if
you
saw
something
like
that
lying
in
the
ground,
would
you
pick
it
up
and
wonder
what
it
is?
A
Yeah
all
right,
few
of
you,
how
many
of
you
would
actually
plug
it
in
to
see
what
it
is
yeah,
so
60
of
those
people
plugged
in
the
devices
into
their
office,
computers
and
they
were
infected.
Luckily,
this
was
a
test,
so
not
that
there
was
any
damage
done
now,
additional
stat
on
that.
If
the
drive
or
cd
case
had
an
official
logo,
90
of
those
were
installed
because
you
just
immediately
trust
it
right.
This
is
what
we're
doing
with
our
public
repositories.
Today,
okay,
there's
several
ways:
attackers
can
get
into
your
system.
A
Some
of
these
techniques
are
now
known
by
name.
I'm
going
to
run
through
these
really
quickly.
Let's
talk
about
the
dependency
confusion
attack.
There
was
a
blog
written
by
alex
berson
this
about
a
year
ago.
He
put
it
on
medium
and
it
talks
about
how
he
discovered
how
you
can
kind
of
trick
people
into
installing
things
they
didn't
intend
to.
A
These
are
package
names.
You
might
be
familiar
with
what
this
file
is
and
what
this
is
about.
This
is
all
about.
You
know,
requesting
the
libraries
that
you
need
and
there's
a
mix
here
of
internal
library,
package,
names
and
external
as
well,
that
are
open
source
turns
out
that
you
can
override
these
packages.
So
if
you
note
here
the
version
requirements,
you
just
need
anything
either
the
version
that's
specified
or
greater,
and
what
turns
out
is
the
default
behavior
of
this
particular
package
manager.
Is
that
if
there's
a
later
version
available
pull
that
instead?
A
Well,
if
this
is
an
internal
package
and
there's
a
publicly
available
package
that
has
a
higher
version,
guess
which
one
you're
going
to
get
you're
going
to
get
one,
you
didn't
expect
one,
you
didn't
even
write,
so
this
is
probably
this
is
pretty
scary
and
caused.
A
lot
of
you
know,
discussion
to
start
happening.
A
A
This
is
the
de
facto
public
registry
for
python.
You
can
just
command,
you
know,
install
stuff
with
pip
install
anyone
can
add
a
new
python
package
to
pi
pi,
that's
the
benefit
of
having
a
public
registry.
Anyone
can
add
a
package
all
right.
This
is
actually
not
just
anyone.
This
is
an
employee
of
jfrog
he's
an
employee
of
our
security
team
and
he
put
a
package
out
there
that
once
you
install
it
there's
code
that
runs
on
the
installation
of
a
package.
It
opens
up
his
website
website.
A
So
he
just
you
know,
put
this
out
there
to
make
a
point:
pay
attention
to
what
you're
getting
and
what
it's
actually
doing.
Our
research
team
does
a
lot.
We've
discovered
you
know
close
to
400
zero-day
vulnerabilities
in
all
kinds
of
packages.
We
do
a
lot
of
work
every
day
to
make
that
happen,
make
sure
that
we
catch
these
and
share
it
with
the
public
we
scan
for
software
supply
chain
attacks.
We
did
this
with
python
and
scanned
about
300
000
packages.
We
got
about
6
000
potential
hits.
A
This
is
one
of
them
or
two
of
them.
One
steals
your
credit
card
information
no
bless.
The
other
allows
for
arbitrary
code
execution
pythagora.
I
mean
these
seem
like
harmless
packages,
but
we
found
them
both
of
them
obfuscated
their
code.
It
wasn't
really
obvious
what
was
happening,
but
these
had
quite
a
few
downloads
and
we're
pretty
scary.
A
How
many
of
you
use
your
browsers
to
save
your
credit
card
information?
Yeah
yeah,
so
it's
safe,
kinda,
safe
from
other.
You
know
places
on
the
web
or
other
tabs
in
your
browser,
whatever
it's
not
safe
from
anything
running
on
your
computer,
and
there
is
a
way
to
actually
get
to
the
database
and
pull
that
credit
card
information
out.
It's
a
problem.
A
A
This
is,
if
you
happen
to
forget
that
at
azure
at
the
beginning,
the
namespace
there
you
get
a
completely
different
package,
so
pay
attention
to
that
turns
out.
There's
lots
of
that
running
around.
We
did
find
those
we
found
at
least
218
packages.
They
seem
to
be
more
like
of
a
test
or
a
bug
bounty
or
something
like
that.
So
thankfully
no
damages
were
done
here,
but
each
of
these
packages
were
uploaded
by
an
anonymized
user.
A
We've
done
a
lot
of
research.
Our
internal
security
team
has
found
a
lot
of
stuff
there's
a
lot
of
efforts
in
the
community
that
are,
you
know
that
brian
talked
about
as
well.
He
talked
about
salsa
a
bit.
This
is
a
really
good
one,
because
it
describes
in
detail
some
of
the
weak
points
of
the
supply
chain
that
we
need
to
pay
attention
to
check
that
out.
A
A
This
involves
having
different
nodes,
become
trusted
package
registries
and
you
could
have
multi-node
verification
of
source
builds,
so
I'm
going
to
speed
through
this
perseid.
Just
so
you
know
is
some
background
on
that.
It's
a
communication
system
that
the
greeks
had
it
seems
to
be
a
very
good
metaphor
for
what
we're
doing
with
the
package
management
the
distributed
network
and
there's
also
a
few
different
ways
that
we
do
this
with
this
project.
A
A
Everyone
needs
to
pay
attention
and
there's
kind
of
an
inflammatory
quote
that
I
found
having
to
do
with
the
thumb
drives:
dropped
in
the
parking
lots.
There's
no
device
known
to
mankind
that
will
prevent
people
from
being
idiots,
so
we
need
to
pay
attention
pay
attention
to
what
we're
doing
and
be
aware
take
what
you've
learned
here
today
go
back
to
your
teams,
share
what
you've
learned
and
let's
take
care
of
this
problem.