Don’t blame security breaches on open source technology – the problem is lack of oversight

A hacker attack recently shut down the ad service OnRamp completely. In an official statement posted on its forums a few weeks ago, OpenX, the parent company of OnRamp, questioned the security of open source technology.

Let me be clear about this: This isn’t an open source issue, and we shouldn’t level blame on open source users and producers (Full disclosure: my company Sonatype is an open source software development firm). Economic and production efficiencies of open source have made it an almost compulsory component of any modern software application. We’ve all reaped tremendous benefits from open source – we develop fast, re-use proven components, and can focus more time on the functionality that’s truly valuable to our employers.

It’s not just that open source is good – it’s necessary. That’s why more than 70,000 organizations made nearly 8 billion requests for open source components from the Central Repository last year for use in all the major categories of applications, including the web, cloud, mobile and critical infrastructure.

The hard truth is that today more than 80 percent of a typical software application is assembled from existing components – and the vast majority of those are open source, coming from dozens, if not hundreds, of individual projects. All industry verticals, both regulated and unregulated, are using tremendous amounts of open source components in both internal and consumer-facing applications.

Open source is essential

Think of software development organizations today the same way you would think of car manufacturers. Developers assemble applications using existing components or parts rather than writing applications from scratch. But unlike manufacturing, the software industry lacks the tools to manage the intricacy and risk associated with a complex and distributed software supply chain.

Component-based development needs to be managed, for sure; security problems arise when oversight is incomplete. Simply put, a flawed software supply chain means flawed applications. Our research indicates that at least 71 percent of applications contain components with known security flaws that are classified as severe or critical.

According to one study, “The Leaking Vault 2011” by the Digital Forensics Association, more than $ 156 billion in direct losses can be attributed to data breaches in just a five-year period. The Application Risk Management in Business Survey by Forrester and Veracode found that 62 percent of surveyed organizations reported breaches in the past year due to flaws in their critical applications.

Mitigating inevitable risks

The question becomes then how to mitigate the risks associated with component consumption while realizing the benefits of open source. Certainly there are constant and sophisticated threats to open source software; this is true with proprietary software too. We know where danger lies: it comes from using outdated components with known vulnerabilities. It comes from not having an enforceable open source policy. And it comes from not managing component licenses or the licenses of dependencies.

It is important to understand that this is a supply chain problem: You need to manage components at each phase of the software development lifecycle — at consumption, in development, during integration and within production.

Decreasing security exposure

Decisive security measures at the component layer strengthen the entire software development lifecycle and increase the integrity of the overall software supply chain. Imagine the risk of a vulnerability in a popular open source component. Because the component is used in many applications, within and across various organizations, it becomes a rich target for exploitation. History has shown that an attacker only needs to gain a foothold in an organization and often attacks the weakest link, so the risk of component-based software development could not be greater.

Here are the keys to decreasing this type of exposure:

Institute an open source policy if your organization doesn’t already have one. If you do have one, review it, and often. Make sure it’s clear to both those on the development team and those responsible for managing the security process – whether it’s risk management, legal or Jim the senior developer – to get buy-in from everyone.
Ensure your policy includes key guidelines for component security, licensing and quality attributes. Beyond the over-arching open source policy that outlines the organization’s standards and values, create additional guidelines to drive usage decisions (e.g. age of component at download, license-type, level of documentation.)
Be sure your policies are enforceable. Without the ability to enforce, honestly, what’s the point? Paper-based policies will be ignored, so look for ways to integrate enforcement into the software development process itself.
Give developers the information they need to make good choices. Your developers are on the front lines so give them the ability to fight. Detecting flaws or non-compliance early on in the process saves time and money down the line.
Before going to production, inventory components and their dependencies. Knowing the makeup of your application is half the battle in troubleshooting vulnerabilities that may be discovered later.
Continuously monitor for newly discovered flaws. New vulnerabilities emerge all the time (just like in proprietary software). You need to know when a new flaw is surfaced, and where exactly the component is being used.
Have a remediation plan. Know how you can fix problems regardless of where they occur in the lifecycle. Fixing flaws isn’t always easy, and having a plan helps.

Open source or proprietary, free or paid, remember this: If we can safeguard the component layer by instituting good component practice it will pays dividends across the lifecycle.

Ryan Berg is Chief Security Officer of Sonatype and former Cloud security strategy lead at IBM

Have an idea for a post you’d like to contribute to GigaOm? Click here for our guidelines and contact info.

Photo courtesy pryzmat/Shutterstock.com.