On Third-Party Libraries and Security
Don’t reinvent the wheel. If you went to a computer science college or read some of the popular programming books, you would often stumble upon this advice, often written in big bold letters to highlight its importance. It’s sound advice, we shouldn’t reinvent things; instead we should improve those things that already exist. Developers nowadays use third party libraries for everything from authentication to visualizations and while doing that has an upside when it comes to productivity, it causes serious troubles when you look at it from a security perspective.
Third-party libraries—as evident from the name itself—are controlled and maintained by external actors, be an open-source community or a commercial entity. When using a library from a third party, we are expanding our threat model to include attacks facilitated through that connection. Developers know this but choose (and continue to) ignore it and use the libraries while hoping nothing will go wrong. But we can’t build reliable security on hopes and prayers.
If you take a look at the node.js package registry NPM, it hosts approx. 1 million node.js packages and it grows by an estimated rate of 700+ new packages every day. PyPi, the package registry for Python, hosts more than 195,000 packages with a growth rate of 134 new packages every day. These two examples aren’t statistical outliers, if we check the popular repositories hosting third party libraries for popular languages we will often find similar numbers to the ones we just mentioned. There is a package for everything, in fact, it’s difficult to think of a specific use case that can’t be fully implemented or at least supported by a third party library.
The British Airways have been in the news multiple times recently after the disclosure of a security breach that resulted in the payment information of some of their customers being acquired by malicious actors who injected a malicious script into a third party library that was used on BA website and mobile phone apps. British Airways were handed a GBP 183mln fine from the British Information Commissioner’s Office, who cited “poor security arrangements” as the main cause of the security breach. This is just one example from a long list of incidents where an attacker chose to hijack a third party library that’s used by their target instead of investing time into directly attacking the target.
It’s easy to learn how to program, it’s easy to write a library and it’s easy to publish it online without much scrutiny or checks. These three reasons resulted in hundreds if not thousands of developers (both juniors and seniors) writing and publishing new libraries that lacks proper security controls or design because—and we hate to admit this—people develop with functionality in mind, security is often an afterthought and for many novice developers a luxury they can’t afford due to various limitations.
This leaves us with an extremely dangerous ecosystem that fosters the addition of new packages and libraries but provides little security protections to those of us who use some of those packages in their applications. Between package registries not hacking strict security controls protecting the publishing functions and developers who don’t securely code their libraries, companies are trapped and face a difficult choice to make, security or functionality- Sadly, functionality always wins.
As a company (or a freelance developer) you need to pay careful attention to the third-party libraries you use in your projects and products. You must maintain useable documentation of all the libraries you are using and for what purposes they are being used. You also need to monitor the news and advisory channels related to all of those libraries to make sure you know about any security issues as soon as they are disclosed. Utilizing some static or dynamic analysis platform to assess the security of third party libraries and their updates can improve your security defenses multiple folds. Most importantly, don’t use libraries for trivial stuff that you can code yourself, think twice before approving a library to be used within a project because that library might cost you dearly if things go south.
Don’t reinvent the wheel but make sure the wheels you use aren’t broken or poorly maintained, because no one likes falling down a ditch when their wheel breaks.
Want to find out what real, bottom up security looks like? Read here…