US DHS Testing FOSS Security
Stony Stevenson alerts us to a US Department of Homeland Security program in which subcontractors have been examining FOSS source code for security vulnerabilities. InformationWeek.com takes a glass-half-empty approach to reporting the story, saying that for FOSS code on average 1 line in 1000 contains a security bug. From the article: 'A total of 7,826 open source project defects have been fixed through the Homeland Security review, or one every two hours since it was launched in 2006 ...' ZDNet Australia prefers to emphasize those FOSS projects that fixed every reported bug, thus achieving a clean bill of health according to DHS. These include PHP, Perl, Python, Postfix, and Samba.
From TFA:
The popular MySQL open source database was not included in the scans for reasons that were not immediately evident.
Any suggestions as to why MySQL has no results? I'm stumped and wondering why one whole corner of a LAMP foundation was left unchecked.
Actually, it would be really nice if it was possible to do it with Microsoft. Microsoft (or most other companies that produce proprietary software) certainly can't do better than what the open source projects do, and certainly their code contains at least as much issues as the ones found in open source projects.
The ability to do code audits has always been one great advantage of open source software, but until now, it was mostly in theory. Now we start to see big code audit projects such as this one, showing that the advantage is real and that the results of the audit are good, since some of the projects have alread patched all of the issues, and certainly most of others will finish patching them soon. This shows that open source is here to stay, is going mainstream, and will not be stopped by any company's interests.
All issues that currently exist on Microsoft's code, on the other hand, will be unpatched. Unless they hire some consultant company (why not the same?) to do the audit on their code (certainly under NDA). But you can be sure that, if they do, for one, they won't publish the results of how many issues were found. No transparency there. And also, probably many issues won't be fixed as promptly as all of them were fixed in many of the audited open source projects. This is not a speculation, if you only look at how long it takes for them to fix issues for which there are security vulnerability reports issued, then you realise that the ones only they know about will certainly take much longer.
First off, prevent is not strictly a security flaw static-analysis checker. It is a static-analysis checker that checks for all sorts of defects. Some of which are directly related to security. Second, I have used prevent extensively over the past year and have found it to be an invaluable tool. It has a pretty low false positive rate and fixing the defects it finds means your code is better. On the code I work on, I find that we have a much lower defect count. But we also have pretty mature code and we really do attempt to make it as bullet proof as possible. But we still have defects.
My experience is with the C/C++ version of tool. We have also been evaluating the java version of the tool and it is good. But some of the free alternatives like findbugs are still better. I would use findbugs w/ prevent for java if I wanted good coverage.
You're right. I forgot to weight them based on the portion of the installation they'd each represent.
It's also unlikely that any real installation would have exactly those packages installed, BTW. Almost any installation will have packages from CPAN, PEAR, whatever Python's central repository is called, some extra stuff like syslog, logrotate, bash, and at least one text editor at the very minimum.
Let's be a little more accurate than multiplying by defects per thousand lines to make up for my previous late-night gaffe. Let's use the actual defect numbers of verified but unfixed and unverified defects.
Apache has 19 defects in 135,916 LOC.
glibc has 0 defects in 588,931 LOC.
Linux has 461 defects in 3,639,322 LOC.
Perl has 12 defects in 496,517 LOC.
PHP has 0 defects in 474,988 LOC.
PostgreSQL has 37 defects in 909,148 LOC.
Python has 0 defects in 282,444 LOC.
That's 6,527,266 LOC and 529 defects. That's 6527.266 TLOC. I get 0.081 defects per TLOC. That's still pretty damn good.
As I said, there's probably some other software on that server, but it starts from a pretty strong base.