Sonatype not out to slam open source

Study highlights open source practices flaw, not software flaws

By  

Stop me if you've heard this one.

A new study from some company reveals that free/open source software is riddled with security errors/license compliance issues/naughty words in the source code and that the company's super-duper products/services are the only thing that will save the day/bring world peace/make a better ending for Lost.

Yeah, thought so.

Which is pretty much what was going through my head when I read Monday's wire reports that software-development firm Sonatype and application security specialists Aspect Security has released a study with a press release that highlighted "[m]ore than 80 percent of typical software applications are open-source components and frameworks consumed in binary form."

That sounds pretty good, right? Here's the sound of a shoe dropping.

"Collectively, Global 500 organizations downloaded more than 2.8 million insecure components in one year," the release continued.

The inference that I, and many people, got from this release, was that open source was once again being pointed out as the carrier of doom and destruction. Certainly Andrew Aitken did.

"It's unfortunate to see this and we disagree with the tone of the study inferring that open source is low quality and risky," said Aitken, Founder and Managing Partner of Olliance Group, in an interview on ZDNet.

Something kept me from launching a full-scale slamfest against Sonatype, because something didn't quite make sense. I've met with Sonatype before. You may recall that they were one of the companies that sided with Oracle whole Hudson/Jenkins brouhaha last spring. Given that they are active participants of the (now) Eclipse Hudson and the Apache Maven projects, I know that they know how open source works. (Moreso, I think, than Oracle.) So why were they apparently tossing out all this FUD?

This was pretty much the first question I tossed at Sonatype CEO Wayne Jackson in a phone call this week to clarify the report. What I learned in the conversation, though, was that this report was not so much an attack on the quality of open source software so much as a warning about how fast open source was getting adopted.

Jackson defended the joint report, but emphasized that it was not meant to berate open source software. The problem, he explained, was just the opposite: open source was so freely available, developers and organizations could have vulnerabilities buried deep in their own code and not even know it.

One of the cool things about open source software is that when developers put together an application, often they won't write a section of code to do action X because someone somewhere has already written a code library or component that performs the same action. So, naturally, the developer will download LibraryX, usually in binary form, stick it in the application, and move on to the next section of code. This is especially true in the Java ecosystem, where Sonatype mostly lives.

The problem, Jackson added, goes further than that. Continuing with the LibraryX illustration, "Say you have LibraryX, and it has components A, B, C in it already. And then component C contains components D, E, and F, and F is found to have a security flaw. Will a developer know to update that one piece of LibraryX?"

According to Jackson, maybe not. The problem is not that open source software has any more or less vulnerabilities than proprietary software--it's just that there is no formal infrastructure in place to ensure that vulnerabilities of any kind will pushed out to the applications.

This is exacerbated by two prevalent poor practices in the open source ecosystem: developers will download software from multiple sources and outside repositories, and then a majority of them don't track what components they are using and where they came from.

"Sixty eight percent aren't keeping track of software through some sort of bill of materials," Jackson said.

And the problem is not a small one.

"There use of these [components] is staggering," Jackson said, adding that one big-bank Sonatype customer has upwards of 14,000 applications. And consumption of these binary components is extremely widespread: Jackson said that he was aware of one major corporation that on its own downloaded and used 2.6 million binary components.

The fact that these are binary components makes it worse, because no one is recompiling them or looking at the source code so the odds that a consuming developer will spot the vulnerability on their own decreases dramatically.

So why is Sonatype picking on open source? It's not for any lack of vulnerabilities on the part of proprietary software. But the use of proprietary libraries often means that some sort of active support agreement is in place, and presumably an automated updating infrastructure. Plus, given the implicit hassle of licensing agreements that encumber proprietary software components, it's a given that adoption of such components should be more closely monitored than the adoption and deployment of open source components.

Given that Sonatype's Nexus product could help alleviate this problem, wasn't this study a little self-serving? Jackson, to his credit, acknowledged this, but also was emphatic about the scope of the problem, and suggested two best practices companies needed to implement as soon as possible to mitigate the risk--practices that did not involve Sonatype's products or services.

First, he argued, companies need to establish and use internal repositories for all software components they end up using. This centralized method will make it easier to keep up to date with any vulnerability fixes and patches, so that any time there's a discovered vulnerability, that fix will automatically be integrated into the components that

The second solution ties right into the first: have developers create a bill of materials for all the components they end up pulling in, and then task someone on staff to correlate the lists and monitor the NIST vulnerability announcements and the Open Source Vulnerability Database (OSVDB) to make sure that components are kept up to date.

Just these two practices alone would mitigate the risks highlighted in the Sonatype/Aspect report, Jackson said.

Read more of Brian Proffitt's Zettatag and Open for Discussion blogs and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness