►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
PyPI Supply Chain Security - Dustin Ingram, Python Software Foundation
The Python Package Index (PyPI) is one of the oldest software repositories for a language ecosystem and the canonical place to publish Python code. It serves more than 2 billion requests a day, and is almost entirely supported by volunteers and the non-profit Python Software Foundation.
In this talk, we'll review some recent supply-chain attack and how they relate to PyPI specifically. In addition, we'll take a look at some in-progess projects to make PyPI more resilient, secure and sustainable.
A
Hello
supply
chain
security,
con,
I'm
dustin
ingram,
and
this
is
pipi
supply
chain
security.
I'm
dustin,
I'm
a
developer
advocate
at
google,
where
I
focus
on
python,
developer
tools
and
experience
and
open
source
security,
I'm
also
a
maintainer
of
the
python
package
index
and
I'm
a
director
at
the
python
software
foundation.
A
The
psf
is
a
501c
nonprofit,
founded
in
2001,
with
3.1
million
in
revenue
per
year.
It's
run
by
a
mix
of
staff,
board
of
directors
and
volunteers.
We
have
nine
paid
staff,
including
some
of
our
accountants
and
our
event,
staff.
We
have
11
member
board
of
directors
and
we
have
a
five
member
steering
committee
and
in
addition
to
these
groups,
we
have
hundreds
and
hundreds
of
volunteers
that
help
us
work
on
our
various
python
projects.
A
Some
of
the
key
projects
of
the
psf
include
see
python,
which
is
the
python
you
probably
are
most
familiar
with.
This
is
first
created
in
1991.
We
also
run
pycon
us,
which
is
the
largest
global
python
conference.
This
was
started
in
1993
and
generates
about
65
of
the
psf's
income,
and
we
also
run
the
python
package
index,
which
was
started
in
about
2002.
This
generates
zero
percent
of
the
psf's
income,
but
about
95
of
the
psf's
liabilities.
A
A
So
one
thing
that
we
did
in
2018
was
a
full
stack
rewrite
of
pi
pi
pipe
had
been
around
and
basically
had
been
the
same
service
since
the
2000s,
and
we
needed
to
basically
modernize
the
web
application
that
that
sits
behind
it.
So,
with
170,
000
of
funding
from
the
mozilla
open
source
support
grant,
we
hired
a
team
of
contractors
and
we
did
a
basically
a
full
stack
rewrite
from
the
ground
up
of
ipi.
A
This
was
successful
and
allowed
us
to
add
a
lot
more
features
that
I'll
talk
about
in
a
second
to
pipi
built
on
this
this
new
platform.
The
first
thing
we
did
here
afterwards
was
increase,
accessibility
and
access.
We
added
internationalization,
localization
pipi
is
now
translated
into
more
than
10
different
languages.
A
We
also
introduced
api
tokens
for
the
first
time
before
that
authentication
was
just
basic,
http,
username
and
password,
and
we
also
added
two-factor
authentication,
both
trtp
and
web.then.
So
now
you
can
use
security
keys
to
authenticate
with
pypi,
which
is
great,
and
that
was
with
funding
from
open
tech
fund.
A
Another
thing
that
we've
done
recently
with
help
from
mozilla
and
the
chan
zuckerberg
foundation
as
we
introduced
a
new
and
improved
dependency
resolver
for
pip,
so
pip
is
the
canonical
python
package
installer
and
it's
the
command
line
tool
that
reaches
out
to
pipi
and
determines
you
know
what
you
should.
What
artifact
should
be
installed
from
a
given
request
to
install
some
software?
We
improve
the
dependency
resolver.
We
give
it
basically
proper
depend.
A
We
have
a
couple
in
progress
projects
as
well
that
I
wanted
to
highlight.
So
one
of
these
is
with
support
from
bloomberg.
We
were
just
able
to
hire
a
packaging
project
manager
for
the
next
two
years.
At
the
very
least,
this
is
a
really
critical
role
for
us,
because
basically,
a
lot
of
python
packaging
and
the
projects
that
I
just
mentioned
were
either
run
by
volunteers
or
hired
contractors.
The
psf
staff
doesn't
spend
a
lot
of
time
working
on
pipi
and
various
features
around
python
packaging
in
general.
A
These
are
mostly
community
projects,
so
we
now
have
a
packaging
project
manager
and
sort
of
community
manager.
A
person
that's
going
to
oversee
a
lot
of
the
future
projects
that
I'll
talk
about
and
sort
of,
help
drive
direction
for
python,
python
packaging
and
the
security
projects.
We
have
coming
up
another
thing:
that's
in
progress
which
isn't
directly
related
to
supply
chain
security,
but
generally
improves
the
posture
of
python
as
a
language
in
the
ecosystem
is
that
we
were
able
to
introduce
a
developer
and
residence
role
for
c
python.
A
So,
with
support
from
google,
we
have
hired.
The
psf
has
hired
a
full-time
staff
member
to
be
a
direct
developer
in
residence
and
basically
work
on
whatever
that
developer
finds
to
be
most
impactful
for
python.
The
language
ukashilanga
is
our
first
developer
in
residence,
he's
about
halfway
through
his
term
as
developer,
residence
and
he'll,
be
he
he's
made
a
lot
of
updates
and
you
can
sort
of
follow
the
work
that
he's
done,
both
triage
and
pr's,
making
new
pr's
digging
into
old
issues.
A
Another
thing
we've
done
recently
with
support
from
google.
Is
we
integrated
the
open
source
vulnerability
project
into
pi
pi?
So
pipi
now
is
aware
of
vulnerabilities
that
exist
on
packages
on
pi
pi,
and
this
was
something
that
didn't
exist
before
part
of
this
was
also
creating
a
community
maintained
advisory
database
of
python,
known
vulnerabilities
in
python
packages,
not
in
python
itself,
which
is
the
advisorydb.
So
this
work
is
now
integrated
into
pipi
and
will
be
used
downstream.
A
And
the
last
thing
is
more
open
source
vulnerabilities
with
support
from
google.
This
advisor
database
is
also
being
used
for
an
in-progress
auditing
tool,
so
we'll
now
have
a
pip
audit
tool
that
is
able
to
inspect
the
local.
You
know,
file
system
or
environment
that
you're
using
some
python
packages
in
and
tell
you
if
any
of
the
packages
there
are
victims
of
some
sort
of
vulnerability.
A
So
the
real
interesting
thing
here,
I
think,
is
some
future
potential
projects
that
we
have
coming
down
the
pipeline.
So,
like
I
said,
malwa
is
a
problem
on
pipi
spam's
problem
on
pi
pi.
We
had
some
recent
press
about
this
and
you
know
basically,
a
project
that
we're
hoping
to
fund
in
the
future
is
improved
malware
detection.
A
Another
kind
of
thing
that
landed
pipi
in
the
press
recently
was
these
dependency
confusion
attacks.
Basically
this
is
you
know,
companies
using
private
indices
and
people
squatting,
the
same
package
names
on
public
indices,
and
you
know
these
companies
installers
were
configured
in
a
way
that
didn't
prefer
the
private
index
over
the
public
one,
and
so
one
way
pipeline
can
improve.
Here
is
namespaces
right
now
all
packages
on
pipeline
exist
in
this
wide
global
namespace.
It
would
be
like
if
github
didn't
have
organizations.
A
Basically,
some
packages
do
use
an
implicit
namespace
prefix,
so
like
some
packages
will
be
prefaced
with
things
like
google
cloud,
for
example,
but
this
isn't
enforced
in
any
way.
It's
basically
up
to
the
publisher
to
do
introducing
namespaces
would
basically
remove
or
reduce
the
ability
for
these
kind
of
dependency,
confusion
or
type
of
squatting
attacks,
because
that
would
allow
pipi
to
block
a
private
namespace.
So
a
company
can
say
this
is
the
name
space
for
our
private
package.
Just
prevent
anyone
from
publishing
this
on
pipi.
A
Another
thing
which
is
a
pet
project
of
mine,
is
that,
basically,
you
know-
and
I
found
this
quote
on
hacker
news.
The
other
day
everything
on
pipeyi
is
just
random
artifacts
uploaded
by
whoever
ran
a
build
script
on
the
machine.
It's
nuts
and
yeah.
That's
absolutely
true.
The
way
that
distributions
are
published
to
pipi
is
basically
a
really
mixed
bag.
Some
folks
do
this
in
github
actions
or
travis
ci
other.
A
You
know,
google
cloud
build
those
kind
of
things,
sometimes
they're
just
running
these
scripts
on
their
machines,
building
the
artifacts
there
and
uploading
them
and
there's
not
a
good
way
to
derive
the
provenance
of
a
built
artifact
from
source
repository
or
something
like
that.
We
don't
have
a
easy
way
to
directly
link
source
to
a
built
distribution
in
that
way.
A
Usually,
you
know,
support
for
these
things
land,
and
then
it
takes
a
long
time
for
them
to
be
adopted.
If
we
owned
a
canonical,
publish
publication
pipeline,
then
we
could
introduce
these
tools
and
everyone
could
benefit
from
them
immediately
and
lots
more.
We
have
lots
of
other
ideas
for
projects.
We
actually
maintain
a
list
of
fundables
here
in
this
repo.