Are we doing enough to prevent future “bleeding hearts”?

As the HeartBleed bug wreaked havoc on the internet over the past few days, we at Sonatype began thinking about the lessons learned from this recent scare and how, collectively, we can develop a process for mitigating the next major exposure.

Was this OpenSSL vulnerability an oversight by system administrators installing unknown software?
The simple answer is no. OpenSSL is the defacto SSL implementation used on most internet servers around the world. This is not an untested, unverified component that slipped by security audits.

A critical question after incidents such as this is: “Is the vulnerable version of OpenSSL still accessible and available for download, whether in a proxy repository or on a public download site?”
This isn't as far fetched as it initially sounds. Let’s take a look at other components that have had well-publicized vulnerabilities:^1</>

• Since March 2009, over 11,236 organizations downloaded (often repeatedly) a known vulnerable version of Bouncy Castle that had been fixed for nearly 5 years. (CVE-2007-6721)
• Since November 2012, nearly 29,468 organizations downloaded a version of Apache HttpClient with broken SSL validation, more than two years after the alert. (CVE-2012-5783)
• Since July 2013, more than 4,076 organizations have downloaded an affected version of Struts2 and are potentially exposed to this vulnerability. (CVE-2013-2251)

Now is the right time to evaluate a process for mitigating these types of incidents.

The proposed approach is a three-step process that becomes a part of the software development life cycle, without slowing it down:

• Have VISIBILITY of the components used in your software
• Use AUTOMATION of policy to eradicate known vulnerable components
• Incorporate MONITORING for vulnerabilities that enables rapid remediation

STEP ONE > Use Automation to Understand What is in Your Software

The process of manually keeping track of components in your application is as outdated as rotary phones or an Underwood typewriter. Automatic inventory and maintenance of a "bill of materials" for managing components is a mandatory part of any modern software development life cycle. There are over 400,000 open source components in the Central Repository, with 13,000,000,000 downloads (yes, that is “Billion”) a year. That means that 27,000 components are downloaded every hour of every day. It is impossible to manage this type of usage without automation.

An automated component management system creates a dynamic inventory of components within your applications and monitors the integrity of those components over time.

STEP TWO > Stop Using Vulnerable Components

The Bouncy Castle, Struts and httpclient examples demonstrate that we, as an industry, are a long way from awareness and action around this problem. OWASP recently added a new “Top 10” with the directive to “not use components with known vulnerabilities'.

We, as developers, have a responsibility to not use vulnerable software. However, there has to be a process built in to the development environment that immediately exposes the security level of components as they are integrated into an application. To see real change in the results of security around component usage, it has to be significantly simpler for developers. Component vulnerability information has to be integrated in to the tools developers use today (and throughout the software lifecycle) and developers have to replace those flawed components BEFORE the application is in production. Jim Routh, CISO Aetna has likened this to using spellcheck in Word. My question is “Why isn’t it that easy?”

STEP THREE > Know what and where new incidents affect you

Because software ages like milk and not wine, software becomes less reliable over time. Eliminating the use of components that have known vulnerabilities is a must, but ensuring you have a component inventory that is monitored for new vulnerabilities is the only way you keep your software secure over time. Unfortunately most organizations struggle to keep an accurate inventory of their components – including the 10’s or 100’s of component dependencies – in each application. So when a new vulnerability is announced, and resolved in a new component release, they don’t even know if they are impacted. While golden repositories and Open Source Review boards all sound good in theory, the math doesn’t work. The sheer volume and variety of open source components sourced into the typical software development supply chain is enormous. And they don’t help once an application goes in to production.

THE BOTTOM LINE > It is time to get rid of this entire “optional” attack surface.
It’s avoidable risk.

By allowing components with known vulnerabilities to continue to circulate and have prolonged life in our new applications, we are only extending our attack surface. It is our responsibility as practitioners in the security industry to educate developers and make it easy for them to create safe, secure applications while giving them the tools needed to provide on time, on budget projects.

Using this three-step process as a framework to identify, eliminate and manage future incidents is a huge step in the direction of creating secure software.

The HeartBleed bug is a single instance of a vulnerability that had world-wide impact. Let's use it as an incentive to update the security industry's vision of a more secure future.

^{1</> These figures are based on Sonatype’s analysis of requests made to the Central Repository (aka Maven Central) during the timeframes noted.}