The first of the four pillars of mobile app security focuses on the use and management of third-party software libraries. Nearly every top mobile app uses these types of libraries. Third-party software libraries are external components that are used in mobile app development. They are important because using them increases speed-to-market and the efficiency of the mobile application development process. The components give top app developers more time to focus on what they do best: being creative and building great software. At a very high level, think of it like the modern car. Many parts are manufactured (developed) by other vendors from all over the world and shipped to a single plant for assembly. This is done to increase production speed and to reduce cost. Just like modern software. Here is a quote from Sonatype: 2016 State of the Software Supply Chain. Just think about how different the stats would’ve been just a few years ago:
“Today, modern applications typically consist of 80% - 90% component parts.”
The mobile apps we ship at WillowTree contain, on average, 18 third-party libraries. When it comes to using NPM with Node.js, that number can easily grow to hundreds if not thousands of dependencies and sub dependencies.
For example, say you have 800 libraries in your web application. How do you manage that many libraries once your application has gone to production? Managing libraries created by the open source community and other companies to make sure you don’t expose yourself to a vulnerability has become essential. A lot of breaches can be directly traced to an out-of-date, third-party library. For example, let say you release an app in January, and in March the networking library you are using becomes vulnerable to man-in-the-middle attacks. How would you know? Because of a growing reliance on third-party libraries, and the uncertainties they can create, we check our libraries against public and private vulnerability databases on a daily basis. Sure, it’s extra work…but it’s as essential as great design and user research to delivering an engaging, secure, user experience. And because the status of a library can change on a daily basis, we continue to monitor them even after apps have gone to production, whether they contain one third-party library or 1000.
Let us not forget the famous quote, “knowing is half the battle,” because it certainly applies here. Bad actors look at the same vulnerability databases we do, and they’re constantly testing defenses and looking for new vulnerabilities. If you are alerted that one of your libraries has a critical vulnerability, it becomes a race against time to remediate it by upgrading, or in some cases downgrading, a library before the vulnerability is exploited. To make matters worse, that window of time for remediation is shrinking, so we all have to step up our game.
At this point, you’re probably wondering how can you possibly manage that many libraries in a project? Seems like a daunting task, right? Well, because this is specialized work, picking the right partner to help you is going to go a long way. When you’re looking for a partner, here are some important questions you should ask:
- Do you have researchers on staff?
- Do you regularly check public and private vulnerability databases?
- How often do you check the third-party libraries in your applications against those databases?
When it comes to finding a vulnerability, there are additional questions you should also ask:
- How do you rate vulnerabilities?
- How easy is the exploitation?
- Actual Impact?
- Low, Med, High, Critical?
- Is the vendor aware and acknowledge the bug?
- Is there Proof of Concept code in the wild?
- Is the vulnerability actively being exploited?
- Do you have practical recommendations on how to remediate the vulnerability?
Having the right partner, and information like this at your fingertips, is going to help you make critical choices. Choices such as helping you prioritize which libraries are going to remediated and in which order. Because we live in an ROI-driven world, there may be cases where you decide not to patch a low-priority vulnerability. To not patch something sounds crazy, but in some cases it’s the only practical course of action.
As you can see, there is a lot to think about here. Hopefully, some of the information here can help you make a more informed decision, and I’d encourage you to read some of Black Duck’s and Sonatype’s blogs on this subject for more info. Some would argue that third-party libraries should not be used at all because of the risks they introduce. In rare cases that is correct, however, I don’t believe that’s where the software development industry is headed. If anything, I see the use of third-party libraries increasing for the next couple of years. Why reinvent the wheel, or networking stack in this case, when the work has already been done?