Heartbleed represented a major problem for the Web as a whole, and with good reason. Breaking into a variety of fronts, disrupting service and doing damage, it was the kind of security problem that most crave any chance to avoid. But there may be one way to forestall the next Heartbleed from coming to life, and that can be found in an unlikely location: third party software libraries.
Third party software libraries, from some reports, represent one of the biggest threats to security at the enterprise level, yet at the same time, are one of the most infrequently considered potential sources of such disaster to consider. The biggest issue to be concerned about is just how much of nearly every app out there is comprised of third party code to some degree, whether open source or otherwise. Reports from industry figures suggest that a typical app is comprised of anywhere between 30 percent and 90 percent third party code. Using such pre-made code bits can help boost app development speed, time to market, and overall profitability as developers can put together more apps in the same amount of time, shaving at least a little time off of each app developed.
But the use of such tools brings with it risk, as apps end up containing a certain portion of code not authored internally and thus not subject to the same controls as the alternative. With no one really responsible for the code, there's not much oversight, and few if any security patches applied should the code prove to have some kind of flaw in it. Even if there's a patch issued, the patch may do just as much or even more harm than good, potentially creating more problems or just different problems. That's the kind of condition that gave Heartbleed its rise in the first place; a particular library known as OpenSSL contained a vulnerability that left encryption keys accessible from the outside, and opened up a staggering number of resulting vulnerabilities in other systems.
So what's the solution? Some might suggest staying out of third-party libraries, but the costs of such a measure could be disastrous. Indeed, some have suggested instead the use of an application security team of some kind, even if one that's only cross-functional or merely informal. From there, such a team can develop policies and procedures to address the potential vulnerabilities of third-party code, and prevent at least some of the potential disasters therein. The alternative approach here can come in app deployment, recognizing that finding and preventing every potential issue is extremely difficult at best and potentially impossible at worst, so instead the defense works harder with technology to protect the system, using dynamic analysis Web application security testing (DAST) or interactive analysis Web application security testing (IAST) in a bid to find and prevent issues.
Regardless of what's done, however, one point is quite clear: something needs to be done lest another Heartbleed emerge, potentially even worse than the last. There's always a need to secure systems and modify that security to take on new and emerging threats, and these are measures that can be taken to provide that security. Something needs to be done one way or another, however, and the sooner it's done, the better overall result will be had.
Edited by Rory J. Thompson