Poor Library Management Leaves Apps Vulnerable

Even if you set out to build your own home, you still likely rely on the tools and infrastructure laid out by someone else. Foundations? Pick up a few bags of cement. Bricks? A trip to a building supplier is much easier than making your own. Electricity, water, and other utilities? Plug into the publicly available services, of course.

This, in a nutshell, is what happens with third-party code for app developers. Sure, they could theoretically write their own code from scratch, but it’s considerably more time- and cost-efficient to use code that’s already been written by a developer (possibly with a whole lot more expertise in certain areas) and to plug this in alongside your own code.

Third-party code is more widely available than ever. It can come from both open source and commercial projects and may be written by a combination of professional developers and amateurs. It’s a game-changer when it comes to the speed at which applications can be written and, often, the quality of what they are able to offer. Not only do third-party libraries mean more rapid software development, but also that development of code in areas where in-house expertise is missing is possible. This can even lead to improved security if performed correctly.

Whether you’re a developer wanting to offer the best product that you can, or a client wanting your app developed as quickly and (without wanting to compromise on quality) cheaply as possible, third-party libraries have been transformative for the way that many apps are created and deployed.

But this approach can also lead to problems. One major example of this is the way that forgotten libraries can create vulnerabilities. For those without protection in the form of tools like WAF, this can pose a major risk. What is WAF? How can it help? Read on to find out.

The problem with third-party libraries

Many people might assume that the open-source movement protects against forgotten, or non-updated, code. As the saying goes: nothing is ever forgotten on the internet. On some level, this is true. The beauty of open source is that it doesn’t rely on just one person to maintain a library, improving it over time to solve vulnerabilities and other potential problems. Instead, open-source draws on the power of the crowd, allowing users from all over the world to contribute to projects like open-source libraries.

This is accurate. However, it ignores the fact that, once a third-party, open-source library has been used by a developer, they must update it in order to keep up with the latest security developers. In reality, once developers have selected a particular library to use there is a high probability that they will rarely — if, in some cases, ever — update it.

Set it and forget it?

This so-called “set it and forget it” attitude is more widespread than one might think. A recent report found that some 80 percent of third-party libraries analyzed are never updated, with virtually every single code repository studied including libraries that boasted at least one notable vulnerability. This study covered 86,000 repositories, containing more than 301,000 libraries. Shockingly, 92 percent of vulnerabilities that were discovered could be plugged if only developers updated to the latest version of the library. In around two-thirds of cases, these fixes would do very little to disrupt the functionality of the software they were used for.

It’s a scary set of findings — compounded by the fact that, for many developers, security lags behind functionality, as well as licensing, when it comes to the decision of selecting a library. It’s also terrifying in its potential damage. The 2017 Equifax breach — in which the private records of a total of 147.9 million Americans, 15.2 million British citizens, and almost 20,000 Canadians were exposed — resulted in costs of $1.4 billion to the organization. The breach could reportedly have been solved with just one line of code to plug the vulnerability.

Protect against risk

Organizations should, as a matter of priority, work to find and update outdated libraries. Other tools are available to help as well. Web Application Firewalls (WAFs) can aid with what’s referred to as virtual patching. This can be used to shield against possible attacks that aim to exploit vulnerabilities using a series of rules to mitigate exploitation risk. Although they don’t change the fundamental code, they are able to respond incredibly rapidly as different vulnerabilities arise, not needing to wait for vulnerabilities to be patched. It’s also a very scalable solution that doesn’t run into the problem of conflicting with other code. Poor library management is a significant risk to every organization that uses third-party code. However, by taking the right steps it’s possible to protect against the inherent risk. Doing so is an incredibly smart investment for any business out there.