Third Party Code: Should CIO's FREAK Out About a Broken HeartBleed?
While it was once understood that any project had to make decisions and tradeoffs, the proverbial “Better, Faster, Cheaper” was always understood that you can only pick any two. Now customers are demanding all three; doing more with less is the new normal for every part of a company not just software development. In order to meet demand, many developers are increasingly turning to established third-party libraries to speed the development process over creating an in-house solution from the ground up. Commercial and open source libraries are often used to help achieve the idealistic balance between the three proverbial options.
The days of a vendor shipping only their own code are also largely over. To save time, adopt open standards, and deliver feature-rich applications, companies rely on third-party software libraries that essentially plug-in to their own. In some cases, that one piece of software can have upward of 100 libraries bundled within. Tens of thousands of lines of code, written by someone outside of the organization, is likely part of that solution you purchased last week.
While this approach increases the speed of development, the belief that libraries are well tested and securely written is in question. Even companies that employ a security development lifecycle (SDL) may not apply those standards to third-party code. It’s important that a CIO understands there is burden to evaluate the security of the wide selection of libraries available, and also that security rarely factors into decisions for inclusion. Software development is focused on integrating the libraries and delivering a working product, not tracking the vulnerabilities associated with each one used within their products.
Prior to Heartbleed, perhaps the most well publicized vulnerability, many organizations were not aware of third-party libraries. Many CIO’s had their eyes opened when they realized the vulnerability potentially impacted thousands of vendors and countless servers on the Internet were vulnerable. Further, many thought that the only companies impacted were ones that were trying to cut corners, and that a mature organization wouldn’t ever use something like OpenSSL, where the vulnerability originated from. But that’s not reality, as many major vendors rely on OpenSSL and were impacted.
As software becomes more interconnected, the potential systemic risk becomes more apparent. One vulnerability can impact many organizations (think Hurricane; one event that causes issues for thousands). When doing further analysis, the very real result is that third-party libraries have the ability to spread a single vulnerability across multiple products, exposing enterprises and requiring vendors and IT organizations to patch the same vulnerability repeatedly.
A CIO needs to ensure that all third party code usage is first identified, and then make sure that their security department is tasked with conducting evaluations and specifically tracking issues in those libraries.
Understanding which products use third-party libraries is required before development or security teams can focus on securing them. Unfortunately, generating the list of libraries used cannot be reliably done with a vulnerability scan. While some libraries can be identified as part of a normal network or application discovery process, in most cases libraries are embedded in a codebase and will not be externally visible. Organizations can either decide to collect this information manually or to make an investment into purchasing a software product that assists with this task. There are several solutions on the market that focus on inventorying all third-party libraries in your applications. While it’s not required to purchase software, it’s important to know that if you request developers to report library usage, it may be prone to omissions and outdated information. Finally, it’s important to remember that usage of third party code can have serious legal consequences if not managed properly for an organization in terms of licensing. Your legal department has the same goals as the security department in terms of identifying all libraries in use and should be involved in this process.
While the exact number is unknown, there are believed to be many thousands of libraries currently being used in enterprises around the world. It’s important for organizations to have the ability to evaluate libraries prior to being implemented in a product. While there are a lot of advantages, there’s a clear cost of ownership associated when an organization decides to use a library. Organizations must make sure it’s clearly known the number of historic and current vulnerabilities in their libraries, along with the time the vendors take to solve issues, which allows you to make the best decision on which libraries pose the most risk. Furthermore, it can be a huge security risk if the library has been declared End-of-Life, with public yet unfixed vulnerabilities present.
For companies already integrating third-party libraries, it’s critical to monitor each library to ensure that newly disclosed vulnerabilities are addressed, either by the library vendor or your own development team that may have to provide a one-off patched version in your products. Companies that want to monitor libraries must understand and prepare for the overhead associated with this task, given the sheer number of vendors, products, and information sources that must be tracked.
The importance of understanding third-party library usage and the potential security issues can’t be overstated. There have been numerous examples where vulnerabilities identified in one product ended up being the result of a bundled library. Having knowledge of these issues not only lets your company be more proactive with security, it allows you to be in a place to have a robust incident response plan for critical vulnerability disclosures that impact your organization.