Fortify: open source software is a security risk for businesses

Fortify: open source software is a security risk for businesses

Here are a few comments on the report; unfortunately, there isn't enough detail in the report to see if there's anything to it or not, and there are a couple of biases and errors that make me wonder.

First, it's Java-heavy. The study author sells a proprietary static analysis tool for Java, so the Java bias is understandable. But their title should have made it clear that they were only analyzing a few Java programs, and not a representative sample of major OSS projects. They also ignored the enterprise support options for these programs, which is completely unjustifiable.

I think its Java bias matters. Until very recently, most Java programs required Sun's proprietary Java implementation. The FSF and others have repeatedly warned of the "Java Trap" (http://www.gnu.org/philosophy/java-trap.html) - so a very large proportion of the FLOSS community has actively ignored Java programs. Sun has recently released most of its Java implementation as FLOSS, and the most recent versions of Fedora and Ubuntu have now integrated it (through Debian hasn't), so I think we'll start to see more cooperation in Java projects.

They made three claims, let's take a look at them...

"Failure to Provide Access to Security Expertise... [aka] documentation that covers the security implications and secure deployment of the software they develop, a dedicated email alias for users to report security vulnerabilities, or easy access to internal security experts to discuss security issues". Odd, they seem to be ignoring the enterprise versions (e.g., Red Hat sells JBOSS support); that doesn't seem to be a fair methodology. They claim a lack of a "dedicated email alias", yet I believe many of these projects are Apache Software Foundation (ASF) projects. If you go to the ASF contact page (http://www.apache.org/foundation/contact.html) the dedicated email address for security issues is clearly listed (it is security, at, apache.org - which you could have probably guessed). Their demand for a "dedicated email alias" and "easy access to internal security experts" shows that they fail to understand that some people want totally open discussions, which these projects do support. They may not LIKE that, and actually I'd agree with them, but claiming that there's NO way to report vulnerabilities or to talk with developers seems fundamentally mistaken. I agree with them that documentation about security needs improvement, though I don't see any evidence that FLOSS is worse than proprietary software on that count.

"Failure to Adopt a Secure Development Process... In virtually every project analyzed, there were a significant number of security issues that went unaddressed over three generations of releases...". It's not clear what these "issues" were. Were these REAL issues, or just reports from a static analysis tool? I wish they'd gone more into this, it's hard to say this is really true or not given their report. Often static analysis tools' reports have LOADS of false positives. As a result, it's hard to see if this is real or not.

"Failure to Leverage Technology to Uncover Security Vulnerabilities: The number of security issues identified in the study - especially in the most popular open source packages - was surprising...". Again, not surprising if what is being measured is raw unanalyzed tool output. It could be that every single "vulnerability" is a false positive (not an uncommon result, unfortunately). I would agree with them that I'd like to see more projects use more tools, but a lot of FLOSS projects do use tools. For example, the Linux kernel developers ended up creating their own static analysis toolsuite because tools are normally designed to analyze applications, not kernels.

The claim that this is representative of FLOSS is unfounded, since it only considers a few Java programs and ignores their enterprise support options (which is what you'd use for an enterprise!). I really wish they'd explained what they meant by issues; the problem of tool false positives is very well known, and I don't see that they really addressed that.

The original said: "Government and commercial organizations that leverage open source should use open source applications with great caution. Risk analysis and code review should be performed on any open source code running in business-critical applications...". Um, let's try: "Government and commercial organizations that leverage software should use software with great caution. Risk analysis and code review should be performed on any software running in business-critical applications...". There, fixed that for you.

And once again, they confuse "open source software" with "non-commercial". Essentially all free-libre / open source software (FLOSS) is commercial, see (http://www.dwheeler.com/essays/commercial-floss.html). Hopefully soon they'll stop making this mistake.