Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Third-party libraries are one of the most insecure parts of an application

Stan Wisseman Chief Security Strategist, CyberRes

Much has been written to guide software developers on how to develop secure software. Despite this general awareness, we continue to see vulnerable software produced. One of the observations in the HPE Cyber Risk Report 2016 is that attackers have shifted their focus from servers and operating systems directly to applications.They see this as the easiest route to accessing sensitive enterprise data and are doing everything they can to do that—including exploiting third-party software components. After all, an attacker looks for any application weakness to gain access to an organization’s sensitive data and doesn’t care how it got there.

Let's look at some of the research around third-party library security and some of the strategies and tools you can use to mitigate these risks.

Fast dev times, for a price

All categories of applications tend to use third-party libraries to accelerate the development process. Based on analysis of the Central Repository (one of the largest open source code repositories), Sonatype estimates that 90 percent of all software development requires the downloading of components. While most critical vulnerabilities in third-party libraries are disclosed as Common Vulnerabilities and Exposures (CVEs), it is disconcerting to note that the applications that use them are not updated in a timely manner. Also, CVEs do not represent all of the vulnerabilities found in third-party software, and other unidentified weaknesses may exist.

A great example of this is the significant security flaw researchers recently discovered in the GNU C Library. A domain-name lookup function known as getaddrinfo() contains a buffer overflow vulnerability that could cause a system crash or allow attackers to remotely execute malicious code (CVE-2015-7547). This vulnerability went undiscovered for seven years and unfixed for seven months following its initial report in July.

Now that an update is available, patching Red Hat Enterprise Linux servers will be a simple matter of downloading the update and installing it. But applications that were compiled with a vulnerable version of glibc will have to be recompiled with an updated version of the library—which will take time. “If open source is used, ensure that the frameworks and libraries used are legitimate and up to date and that the compiler used hasn’t been compromised,” warns Gartner.

The Cyber Risk Report 2016 researchers examined results from the HPE Security Fortify Open Review (FOR) project, focusing on libraries and frameworks for PHP and Java (the FOR dataset for other languages was statistically insignificant). As summarized by Jaikumar Vijayan in his TechBeacon article "State of app security: Most common vulnerabilities, top trends," “…data showed that code quality, input validation, and representation errors and vulnerabilities in security features topped the list of most common vulnerabilities in open-source libraries just as they did with open-source applications.”

Libraries in the hot seat

In general, the FOR data shows that only about 9 percent of all scanned applications that use at least one open-source component upgraded at least one of their libraries. Within this data subset, only about 5 percent of applications upgraded to the latest version of the library. Overall, 49 percent of applications referencing open-source components used the latest version of some library.

Configuration management is essential in protecting your software supply chain and should include inventorying any open-source components to ensure full traceability. The FS-ISAC recommends that developers apply policy controls during the acquisition process as the most proactive type of control for addressing the security vulnerabilities in open-source libraries.

They also recommend managing risk by using controlled internal repositories to provision open-source components and block the ability to download components directly from the Internet. While development teams may grouse about the application of these controls, they are much less expensive to implement than remediating security defects after they are deployed in production.

Developers can no longer afford to use third-party libraries without also keeping track of the libraries' updates and security profiles.

Keep learning

Read more articles about: SecurityApplication Security