Third-party software libraries introduce efficiency and risk into enterprise applications. Two researchers will identify some of the most vulnerable libraries during a talk at the upcoming Black Hat conference.

Enterprise application developers are under real pressures to push projects out the door quickly and cheaply, and each new version certainly has to be better than the last. This forces them to make decisions that, at a minimum, improve efficiency—and also introduce additional risks.

Of particular concern is the use of third-party software libraries pulled in to help speed up the development of portals, shopping carts and other business and customer-facing applications. Such libraries have been under increasing scrutiny since the disclosure of the Heartbleed vulnerability in OpenSSL, which had Internet-wide implications on the integrity of online communications and business.

OpenSSL is the most high-profile problem of late, but it’s certainly not the only one. Hundreds of open and closed source libraries are used, each with their own set of issues that often aren’t updated or patched with any consistency.

“Developers are using these things, and what’s not being recognized is that there could be anywhere from 50 to 150 third-party libraries that make up a single application,” said Jake Kouns, cofounder and president of the Open Security Foundation which runs the Open Source Vulnerability Database (OSVD). “Many companies may have a secure development lifecycle implemented and do a lot of security checking, but at the same time fail to realize that a lot of code from other places is being pulled in and not getting the same level of scrutiny.”

Kouns, along with Kymberlee Price, director of ecosystem strategy at Synack and former security program manager at BlackBerry and Microsoft, will present research on the use and risks associated with third party libraries at the upcoming Black Hat USA conference in Las Vegas. Kouns and Price will focus on OpenSSL during their talk, but will also identify some of the other less high-profile libraries such as libpng, freetype and ffmpeg, that are most putting application security at risk.

“I think the lifecycle of a third-party vulnerability is a lot longer than the lifecycle of a native vulnerability,” Price said. “With the traditional incident response model, the vulnerability is reported to the vendor who identifies it, assesses its impact and releases a fix. When a library such as libpng releases a fix, [a vendor’s] customers in IT can’t manually update the library in a product. They have to wait for the vendor to update it and the incident response time is vastly extended. It becomes very recursive at that point; the update cycle is essentially doubled.

Price and Kouns said developers are hardly proactive about seeking out updated libraries unless there’s a Heartbleed-type event.

“The problem is really twofold. You have companies using products they should have never selected; the upfront selection process is basically grab anything that’s available and they’re not doing [security] evaluations,” Kouns said. “They’re not looking if this library has been end-of-life or if there are vulnerabilities that have not been updated in a while. They’re making poor decisions they have to live with in code over a long period of time, and then there’s a lack of monitoring to see if anything has been happening since. They’re focused on their code and not on any of the other components.”

Price pointed out as well that libraries that are not updated frequently could also be many versions out of date, to the point that when a Heartbleed happens, there are “painful” architectural changes required, she said. Heartbleed led to a perfect storm for OpenSSL users; the crypto libraries are in hundreds of vendor products, mobile applications, websites and more, and updating to current versions was a challenge on many levels for organizations.

In their talk, Kouns and Price are expected to dig into other libraries that are buried in hugely popular online applications and operating systems, ranging from numerous Linux flavors to PlayStation consoles, multiple video games and streaming services such as YouTube, DirectShow and QuickTime, from Google, Microsoft and Apple respectively.

“If you’re daughter plays the American Girl Doll video game, freetype is in there; FFmpeg is in YouTube,” Price said. “We’re trying to shine a light on the darker corners of the third-party ecosystem, not just OpenSSL.”