Ben Langhinrichs

Photograph of Ben Langhinrichs
E-mail address - Ben Langhinrichs






April, 2017
SMTWTFS
      01
02 03 04 05 06 07 08
09 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30

Search the weblog





























Genii Weblog

With open source software - trust but verify

Fri 15 Aug 2014, 09:49 AM



by Ben Langhinrichs
I was very interested to read Paul Withers' article, 10 Reasons All Companies Should Use Open Source. I agree with many of its points, but wanted to bring up one caveat that seems too often ignored. If I might throw some caution on his first point, 1. Good Developers Write Good Code, Great Developers Steal Good Code, it would be to remind people that great developers can steal bad code as well.
As the Goto Fail vulnerabilty, and even more the Heartbleed Bug should remind us, the fact that code is widely used or open source, even widely used open source, does not absolve a company using it from testing. It should be assumed to be buggy, insecure and incomplete until proven otherwise. Personally, I think any open source library added to your own software should be treated as if it were written by the most junior developer. It might be great, but it also might have glaring holes that are waiting to trap the unsuspecting. As I wrote when the Goto Fail vulnerability surfaced, the great failing was not that the code had a bug. All software has bugs. The great failing was that Apple's QA didn't adequately assume it might be vulnerable and try to attack it to see if they could get through. As the Heartbleed bug proved shortly thereafter, the problem was even more prevalent when the code was open source, as it seems that many companies trusted OpenSSL when a relatively straightforward QA test should have shown that the vulnerability existed.
 
Trust but verify. Open source code (and your own code for that matter) may be very, very good, but you should test it as if it were buggy, insecure and incomplete. Do not trust "the crowd" to do your verification for you. In fact, with open source code you should add the element that a nefarious somebody may have planted a subtle vulnerability, so you should push the limits and assume the worst.
 
Note: If you find any problems, especially security issues, you should make sure the open source code is fixed and submitted to the originator as well.
 

Copyright © 2014 Genii Software Ltd.

What has been said:


1095.1. Nathan T. Freeman
(08/15/2014 09:23 AM)

You can replace every instance of "open source" here with "proprietary" and the statement is exactly as true. Apple, Microsoft, IBM, Oracle and SAP ship software with as many security vulnerabilities as OpenSSL, Apache, Eclipse or the Linux Foundation. The "nefarious somebody" planting a vulnerability is even more likely with proprietary code. In fact, we know now that it's a virtual certainty with the NSA forcing major vendors to provide secret access through National Security letters.

At least with Heartbleed, once the threat was identified, there were thousands of developers and organizations that could act to fix it. There is no one that can fix the governmental backdoors into Skype or Facebook or Google or Hotmail or RSA except the occasional journalist that gets enough hype out of a piece to force the lawyers at big corporations to file federal lawsuits just to allow them to disclose the extent of the vulnerabilities.


1095.2. Paul Withers
(15/08/2014 09:31)

A very valid point. But I would dispute anyone using that as a reason to tell developers not to use open source. As a developer or a consumer, sooner or later you've got to trust developers. All those Apple users trusted Apple. Yes, there's a failing of Apple's QA. But playing devil's advocate, should the consumer equally QA any software they choose to use, if all software has bugs?


1095.3. Ben Langhinrichs
(08/15/2014 09:40 AM)

Nathan - Absolutely true about proprietary code, whether you wrote it or not. My worry is that there is a certain mystique about open source code (in the way that technology seems to attract quasi-religious faith) that leads some to think that it is somehow invulnerable. I would treat proprietary libraries with exactly the same degree of caution as open source libraries, but I have debated with people who seem to feel open source is automatically safer because you can see the source code. That is simply not true, hence my caution.


1095.4. Ben Langhinrichs
(08/15/2014 09:46 AM)

Paul - Since all software has bugs, it provides no safe haven to write your own, and it is often better to rely on code from others, whether proprietary or open source. But as to your second point, it is unreasonable for consumers to QA the software they buy, which is why companies are responsible for the process. Nonetheless, do you trust any software or device you buy absolutely, or do you keep a sense of caution? Rudi likes to tell stories about how customers in Germany (a rule following place) wound up driving into rivers or off the road because their GPS said to. We have to trust software and hardware within reason, but we also have to trust those who sell to us to do due diligence. As a vendor of software, that is my job, whether I am using software I have written, bought or gotten for free.


1095.5. Nathan T. Freeman
(08/15/2014 11:40 PM)

Pingback http://nathantfreeman.wordpress.com/2014/08/16/top-ten-myths-about-open-source-in-corporate-it/