foreign
but now
we have Evan Bromley where we will be
working out how to pick the right third
party packages for your project let's
make Evan feel welcome
[Applause]
all right awesome so good eight my name
is Evan Brumley I'm the software
engineering lead at WSB digital in
Melbourne
um and today I'm going to be talking
about this little guy
um so pip install like if you look at
any Python tutorial or particularly
Django tutorials the time to pip install
can usually be measured in minutes it's
one of the first things that we have
beginner programmers do
and it's not necessarily the safest
thing
um so today I'm going to be talking a
little bit about packages and how to
pick the right one
so let's start with a little case study
so it's February 9 2023
my crypto wallet is empty my web3
Enterprise is ruined my apes are gone
can anyone take a look at my
requirements.txt
and tell me what's happened
no Django rest framework is actually not
supposed to have dashes
um that will catch you out that's caught
me out in the past but you're on the
right track the actual one is Matt
plutlib
that should be matplotlib
I've made a typo
and that typo has cost me dearly because
on February 9 2023 some Bad actors
uploaded about 400 and something
packages to pipe EI of common
misspellings of packages
and Matt plutlib was one of them
um those packages tended to be revolving
packages that were to do with the crypto
Community or or packages that crypto
people use and the costs of installing
matplotlib for me was that a browser
extension was downloaded and installed
on my machine which quietly switched out
crypto addresses on my computer
clipboard so when I went to copy one
cryptocurrency address it switched it
with the attackers cryptocurrency
address and I set my Apes to someone in
North Korea
um there is a really great write-up I'd
suggest having having a look at that
link um they go into quite a lot of
detail about what happened
um but the point I'm trying to make here
is that packages
um are not necessarily safe they have a
lot of power they have the same power
that your application has
using other people's code is the
riskiest thing you can do in software
engineering short of writing your own
code
so
this talk is about how we can manage
that risk
in this talk I'm going to be presenting
a framework this is kind of the way I
think about packages when I'm looking
picking the ones to install
I'm just going to start with talking a
little bit about identifying your
Project's risk profile which is
basically determining your appetite for
risk in packages
I'm going to talk very briefly about
architectural fits so how to pick the
right packages for your project from a
purely technical you know do they do
what they should be doing perspective
and then I'm going to talk about risk
from a few angles so licensing risk
security risk maintenance and quality
risk and I'll go through those in detail
I'm going to talk about finding
Alternatives and then I'm going to talk
about if you can't find Alternatives how
do you mitigate the risks that packages
present
so let's start off with risk profiles
so what is a risk profile I'm kind of
defining it as a Frank assessment of the
dangers that your app will face in the
wild and the dangers that your app could
pose to others this could be a formal
document something that you put together
um you know if you're working in a big
project your project manager might be
involved you write up a big PDF and
present it to your stakeholders or if
you're working on a personal project
this could be a super informal thing it
could be just a picture in your head and
an understanding that you have
the most important thing is that once
you establish your risk profile you
should be sharing it with everybody on
your team everyone on your team needs to
have a firm understanding of this
so
here's some kind of example examples of
where projects can fit on a risk sort of
Continuum these are just some sort of
categories that I've dreamed up nothing
official but just a starting point for
how to think about risk so a low risk
project might be uh you're a personal
project some proof of concept code
something that's not on the public
internet
um but something that has kind of a
short lifespan
um so something you're not going to be
supporting super long term
you'll then work up through medium to
higher risk as your map moves on to the
public internet or on a local corporate
intranet as your the length of time that
you're going to be supporting this app
increases you're going to have to be
starting to think more carefully about
the app the packages that you
incorporate into your app and the
effects that they're going to have long
term and on security
Etc and you know we move all the way up
into the extreme risk category let's say
you're working on government projects or
military projects if you have a high
volume of sensitive or personal
information particularly if you have
vulnerable users
um you know for whom if data got out
then that would be a huge problem and
cause you know significant issue or if
there's a high likelihood a targeted
attack if you're if your app is likely
to be targeted by you know Bad actors
you know specifically looking directly
at your address at your app and trying
to break it then you kind of fall into
that extreme risk category and you
should be you're being extraordinarily
careful with any application code you're
doing full review
um so
why do you need one of these these risk
profile forms up the basis unusual way
up all of your risk related decisions
for your project
it's important to communicate this
carefully with all of your team because
risks may not be immediately clear to
everyone on your team especially in a
standard project you'll have junior team
members senior team members you know
people come from different experiences
um so it's really important that all of
those risks are fully understood by
absolutely everyone because they may not
be obvious
um final Point here teams can sometimes
Sleepwalk into high-risk situations with
their applications when you're picking
your packages you'll pick ninety percent
of your packages in the first week of a
Project's lifespan
and if you haven't already thought about
your risk profile then you may find that
it's too late and projects can sometimes
also move from low to high risk over
their lifetime so continually revisit
your risk profile
so I'm not going to talk a little bit
about
architectural fit and I'm not going to
go into huge detail here because this is
basically sort of you know it's a skill
that you'll build up over time and
there's an awful lot to take in but I'm
just going to give you a few sort of
questions to think about
the first question most important one
from my perspective is do you really
need it
um
people have this view of building Django
applications as kind of constructing
applications out of Lego you know you
look at the Django wait Django apps are
Django bomb projects are
performed and they're sort of where it's
apps you have apps and you have you want
to do like if I want um your to-do's and
I'll install a to-do app I'll go out and
find a to-do app on the internet in a
package but a package is not always the
right fit
um so it might be a trivial bit of
functionality that you could do in a few
lines of code it might be something that
isn't really architectural best practice
um you know there's an awful lot of you
know Django Dash something Dash
something something packages out there
that are combining things in weird and
wonderful ways
um and you know maybe you should think
about looking at it holistically looking
at Best Practices and and you know doing
your research and more research and just
Googling for a package
next look at where you'll be using this
package correctly are you using this
package as the authors were intending it
to use if you use a package in a unique
and unexpected way do not be surprised
if a minor update breaks it in a unique
and unexpected way
um number one rule of programming don't
get clever
um so make sure that you're using it as
intended that you're not hacking it
together and if you do have to hack
something together for whatever reason
document it incredibly carefully and
make sure that that is you're known to
everyone on the project that you've
accepted that risk
lastly have a look at how will it affect
your code base
um you know many packages have very
strong opinions over how you should
integrate them how you should code
around them in some cases that's a
really good thing think Django Django is
a framework it guides you to the best
practices
um but you know some applica some
packages will guide you in different
competing directions so take a holistic
view of your application look at all the
other packages that you have installed
and how your bet what your team's best
practices are and make sure that the
package is actually going to be
enforcing the right patterns for your
project
good dependencies tend to solve
difficult problems like cryptography or
web Frameworks
they tend to have clear and ring fence
responsibilities
as I mentioned they do the job they were
specifically designed to do in your
application and most importantly they
leave your application room to grow so
they open doors rather than close doors
as I mentioned this is a core
architectural skill that comes with
experience so do deep research look
Beyond just Googling for packages expect
to make mistakes
every single application developer will
have that one thing that they installed
that they really wish they hadn't
um and ask for help because this is a
skill that's gained over experience you
know reach out to your fellow developers
come to conferences like this talk to
people ask people how they solve
particular problems and really rely on
the um on the experience of others to
learn
okay so now moving on to analyzing the
actual risk from a package I'm going to
look at sort of four types of risk
licensing risk security risk maintenance
and quality risk and I'm going to look
at these ones in turn and how to
identify these risks and how to sort of
how to gauge the levels of risk on
particular packages
so I'm going to start with another case
study
so I've just launched my startup with 30
million in dollars in seed funding my
app is really really cool it connects to
your git repo and runs a bunch of sort
of common linting rules and then
automatically generate some code review
comments uh I built the entire thing off
open source code I didn't have to write
any LinkedIn code myself it's great I've
relied on the open source uh Community
to do most of that work for me
um however my primary investor has just
left me an very angry voicemail and says
that I have to meet with the lawyers uh
first thing on Monday
can anyone spot from my requirements.txt
the mistake I've made
so what I've actually done
you may not have realized this but
pilint is GPL code
you cannot use pilint you cannot
incorporate Pilots code into your
project in a functional way you can use
it as a tool to analyze your code base
but if you try and build a product off
it then by by having it licensed onto
GPL you have now essentially committed
to open sourcing your entire product
under the same license
so I need to immediately stop using that
package or open source my app
and this is sort of leading into
licensing risk so licensing risk is the
risk of using Code that is not yours to
use
and also the risk of accidentally open
sourcing your entire project
um there is really like this is an easy
one to check always check the license
um there are some licenses that you can
probably use
um these are known as permissive open
source licenses they include MIT Apache
ISC BSD Clauses bsdn3 and two Clause
um these licenses give you a lot of
freedom to use that app that code in any
way you want you can effectively use it
for commercial purposes
um you know for personal projects
anything you like there's no warranties
provided
um but you know you can use it and you
can build commercial applications off it
there are some licenses that you almost
certainly can't use those include the
GPL licenses GPL V2 V3 agpl lgpl these
are kind of known as share alike
licenses or viral licenses and you have
certain obligations under those licenses
if you use that code and for those
licenses usually that you release the
code under the same license
the Creative Commons licenses can be
permissive but you have to look at the
detail every Creative Commons license
will have a certain list of suffixes
after it some of those are permissive
and some of them are not the ones that
I've listed there uh create a common
share alike is has the same issues as
those GPL licenses
um ccnc means non-commercial you can use
that code but only for non-commercial
purposes
um and ccnd means no distribution which
means that you can look at that code
they've released it so that people can
see how things work um but you are not
allowed to use that in any way
finally if there is no license provided
on a project you can usually see this by
looking for a license file
in the repository if that license if
there is no license file you cannot use
that code that is considered All Rights
Reserved there's a link to a GitHub
readme there which I highly recommend
for having So reading up on open source
licenses
so next and this goes back to that first
case study I presented the security risk
so this is primarily the risk of
security vulnerabilities it's the risk
that an app will contain code that while
not malicious
does contain some vulnerabilities that
could open up your up your project to
attack it also includes the risk gold
packages that are in fact malicious like
matplib
and the risk of previously benign
packages becoming malicious due to a
change over or someone taking over that
project and inserting malicious code
so what are some positive indicators
what are some things to look for to
indicate that that security risks are
being mitigated on a project on an
application so
um
first point regular activity and this is
going to be you're going to see this one
across all types of risk as a grid
indicator
you want to make sure that people are
actually regularly committing code to
that um to that package look at the
commit history look at the release
history it's actually very important to
look at the release history as well as
the commit history because if they are
committing every day but they haven't
had a release in three years that
doesn't really help you very much
but a package that's being actively
worked on is less likely to have
security vulnerabilities because people
are actually looking at the code
similarly High popularity which you can
look at by GitHub Stars although they
can be misleading and pipei downloads
look and see how many other people are
using this package there is some level
of safety in numbers it's not absolute
safety but it's a good start
um because you know other people might
you know be attacked first
um or um you know there might be more
people more scrutiny on a package it's
very commonly used
um active community and this is kind of
separate to activity but active
community means is there a good set of
contributors who are who are looking
into a project is it not just like one
guy
um you know do they have a sort of a
diverse set of people of eyes looking at
this project to spot things that one
person could miss
some more specific security related
things do they have a rapid response to
vulnerabilities if people report things
on their GitHub issues or if it's a
bigger project do they have cves raised
against them how rapidly does that team
respond to those vulnerabilities
look for a responsible disclosure policy
so this is a policy that's usually
advertised on a project home page or on
a GitHub repo basically giving
instructions for how to report
particular vulnerabilities
um without putting them onto a public
issue tracker so that bad actors can see
them
and lastly and these are pretty rare on
open source projects but great if they
have them but third-party assessments
and penetration tests are awesome you
know some bigger projects will will have
them they'll go out to third parties and
and um and say can you take a look at
this code look in detail of this code
and see if you can spot anything
and they'll usually advertise those on
the project home page
some negative indicators so some things
that not necessarily like um like deal
breakers
um but things that you that can raise
the risk on of security risks
um if a package is doing higher risk
activities so examples here like Payment
Processing authentication cryptography
anything to do with cryptocurrencies
those that means that that package is
more likely to be targeted in an attack
um so any vulnerabilities in in there
are more likely to be found and
exploited so do a careful review
um you know consider how the package
does what it does some high-risk
activities can be hidden in the
background
um so really do a deep dive on to like
what you know just think hard about what
those packages are actually doing and
whether there is anything there that's
likely to be dangerous
um Logitech surfaces so these are apps
that are doing inherently risky things
in terms of
um
like public like calling system
functions or for instance Django is a
great example of a package with a larger
tax surface
um you know it has web processing all
the stuff that we've seen handling we're
handling HTTP requests
um cookies authentication cryptography
um all of these things are avenues that
the Bad actors would really like to
Target
so you expect a higher level of
governance and and security and testing
on projects that have those sorts of
attack surfaces
so moving on to maintenance risks these
are this is the risk that a package will
degrade over time that it won't be
maintained that'll be difficult to bring
in-house if it does fall out of
maintenance
activity popularity and Community are
really important points here I'm not
going to go over them again but
basically if a um if a package is really
is actively maintained and popular and
has a great Community then there is far
less risk that it will not be maintained
in the long term
um some more specific things backing by
organizations if it has funding or there
are a lot of big organizations that are
using that it's a really good sign if
they have financial support which is
sadly very rare in the open source
Community but if there is financial
support then it means that the
development is likely more sustainable
um also if an app has sort of a package
has evergreen functionality which is
sort of you know very self-contained
functioning functionality that's
unlikely to change over time examples
being sort of algorithm implementations
um or if it's processing uh um if it's
passing a protocol it hasn't changed
since the 1980s then if it hasn't been
updated in a few years then look it's
probably fine
and some negative indicators there if
it's only backed by one organization and
completely owned by one organization
then you should be looking carefully at
that organization's track record for
maintaining things it's not a guarantee
if it's open source now it's not a
guarantee it will always be open source
um so you know be very careful if you're
sort of using your
ex-organizations I'm I shouldn't say x
um why organizations
um uh you know package because there's
no guarantee it'll be supported tomorrow
because you know organizations are
fickle
um also look for packages with a really
high support burden if it's very complex
functionality rapidly changing subject
matter if they're depending on external
apis that change rapidly then the burden
on those on the developers of that
package is likely to be higher
um so
um you know there is a greater chance
that they might burn out if they don't
have the necessary supports in place
so finally this is kind of the trickiest
one
but quality risks
um risks that the package won't perform
as advertised it will be buggy might be
difficult to work with or it'll force
you into bad practices in your code
um
again activity popularity Community
really good signs but look for project
governance if you can't actually dig
deep into the code because you don't
have that sort of level of experience of
looking through python code look for the
governance processes so look for you
know do they have sort of detailed
release notes do they have really good
solid documentation that's easy to read
do they have formal deprecation policies
like look into Django's deprecation
policy for a really fantastic example of
how that should be done in a project
with great governance
and lastly look for test coverage
um so you know a test Suite is a great
indicator that those developers actually
here are working in a professional way
and really care about their work
negative indicators really you just have
to dig into the code and have a look but
that's tricky
um you know go and if you need you know
go out and reach out for help ask your
senior developers and other people in
the community to have a look at a parrot
package and see what they think of the
code does it conform to best practices
Etc
so I've covered a lot of indicators
there luckily there is a really helpful
tool out there called sneak advisor
sneak advisor is essentially a database
of every pipei package out there as well
as actually npm packages and rust
packages and go packages
and you can type in any package that's
on pipe EI and it will give you a report
like you see here
these reports cover a lot of all the
things that I've just talked about in
particular activity and Community
licenses it will have a big flat a big
warning if something is in a
non-permissive license it'll give give
you graphs of popularity over time
commit frequency releases and it will
coalesce all of that into a score so you
can see Django scores very well 96 out
of 100.
um and it gives you like helpful badges
up in the top top right that tell you
where particular packages might fall
down or what you should be aware of so
highly recommend if you're looking at
packages type them into here have a look
and see what it says
so finally if we're looking for
alternatives to pack picture packages
um
let's say that you you don't like a
package it does an unacceptable risk
profile
um how do we find Alternatives so
my first point the first Google result
may not be the best option Google
results are fickle
um and they will frequently give you the
thing that you search for if you search
for you know Django react date picker it
will give you some package called Django
Dash rate Dash react Dash date picker it
won't tell you that you should be
integrating you think about you should
be thinking about those things entirely
separately
um so yeah do do a sort of back to basic
search look for lots of different
keywords do searches on pipei look on
Django packages.org which has been a
long-running fantastic resource that
tells you gives you sort of Matrix views
if you give it a particular topic then
it will give you a view of a whole lot
of different different packages that do
that job ask around ask on forums go to
conference go to conferences and meetups
and talk to people
um finally how do we mitigate risks
every package has some level of risk
most packages will fail at least a few
criteria even good packages die
eventually and sometimes only one
package does the job and it hasn't been
updated since 2013 but we can manage
that risk to some extent
first off licensing risk there's not a
whole lot you can do here I recommend
asking the developers nicely to change
the license this has worked for us in
the past
sometimes developers especially
developers who are new to open source
will look for open source license C GPL
and say yes that's the one because it's
an open source license and not really
understand the ramifications
um so you're filing a support ticket and
asking nicely if they could change it to
a permissive license can be a good
option
that doesn't work talk to a lawyer there
are some ways that sometimes that you
can integrate that code but you have to
be extraordinarily careful with how you
structure it and it really needs a
lawyer involved so generally avoid if
you can but otherwise your company's
lawyers may help
mitigating security risk supply chain
scanning tools these are really handy
they will look through all of your
requirements and give you advice on on
tell you if there are any security
vulnerabilities on on particular
packages a great free one is dependabot
which is free with GitHub there is also
safety which is free for non-commercial
use that's a command line python command
line application that you can run on
your requirements there's also sneak
which you run that sneak advisor
platform they are very expensive but
they're also in the industry later in
the area
um perform careful code review
commission penetration testing if you
have budget you can host your own
package repository to avoid packages
being swapped down under under you
and just generally having a good
security posture on all of your servers
on all of your development machines
install virus scanners do all the things
you should be doing for organizational
security
mitigating maintenance risk pay your
open source developers
Financial contributions are the best way
to keep packages maintained if you can't
pay for your packages contribute to open
source projects in kind so contribute
code you know get your set up your
organization to be able to contribute
back to the open source community
support the work of development
collectives like jazz band which is a
group of developers who collectively
maintain particular packages and if all
else fails you can always vendor a
package and maintain it yourself but
that has its own bundle of risks
involved
and finally quality risk this is one of
the most difficult ones but pinning your
dependencies if you believe that a
package might be sort of prone to
changes between minor versions Etc or
they might not be the best governance
practices in place pin those
dependencies and watch them like a hawk
um code defensively
and write wrapper code to contain
Madness
um so your broad accept statements as
much as pilot will will and um uh will
be annoyed
um you know make sure that you're
capturing everything that can go wrong
in a project in an architectural sense
um and make your own contributions to
help out the maintainers you know be the
change that you want to see in the world
and and make code better
my three key takeaways
know your Project's risk profile make
sure you understand how much risk you
want to take stop and think before every
single pip install
and plan for the long term plan for
maintenance plan for what will your app
will look like in five years
um you know contribute back to the open
source community and make sure that
these packages are maintained long term
and finally watch out for typos
thank you so much
[Music]
[Applause]
thank you for that Evan we do have a
couple of Discord questions but we've
probably only got time for one of them
are you okay with answering the Discord
ones after in a live one now yep
excellent so people on the internet you
heard him he will be replying on Discord
but for the people in the room
one lucky person can ask one lucky
question here we are the lucky winner
the wonderful person in the very well
matching uh mask
um just about the licensing
compatibilities
so uh you had quite a list of there of
the share like licenses but uh like this
is a a Django con so we build websites
we don't distribute code we run the code
on our servers and people access it so
um all uh pretty much all the licenses
there listed are for code that is being
distributed except agpl agpl was created
specifically uh for uh for servers for
services so that if you use GPL if you
use that code to run a service on a web
server then you have to make that code
open source the others you don't have to
worry about because you're not
Distributing in the code so was there a
question there
uh
am I wrong
ask your lawyer
um I'm not going basically my advice is
don't get into like when it comes to GPL
code whether it be any of the variants
don't take any of it for granted be
extremely careful
um and you know you might be able to use
it in your application but it has again
it depends very much on the subtleties
of of the particular license involved
there is no real good catch-all yes you
can absolutely use this if you're
building a web application so yeah um
basically ask your lawyers get approvals
from from the people who really know the
stuff I'm I'm not an expert on that I
tend to just go with if it's permissive
great otherwise
yeah look deeper ask a lawyer
let's thank Evan again for his wonderful
talk
[Music]
[Applause]