This story was originally published on Aug. 7, 2009, and is brought to you today as part of our Best of ECT News series.
Code hunters are spotting with greater frequency defective coding thatcould open security holes in free and open source (FOSS) software.
The Open SourceReport 2008 and the Architecture Library Report, conducted by Coverityfor the U.S. Department Homeland Security Cybersecurity Open SourceHardening Project, shows more than 10,000 defects fixed since projectlaunch in March 2006.
The report, delivered in July at the OSCON 2009 (Open sourceConvention) gathering, used the same analysis tools and configurationsas the Scan Benchmark 2006. The results are based on analysis ofover 55 million lines of code from more than 250 open source projectsthat represent 14,238 individual project analysis runs. All totaled,nearly 10 billion lines of code were analyzed.
By understanding possible code execution paths, defects are identifiedand eliminated by open source developers, according to the report’sauthor, David Maxwell, Open Source Strategist for Coverity. The codeanalysis used Coverity Prevent, a static code analysis tool thatdelivers path simulation, data flow analysis and false path pruning.
“It is the responsibility of everyone who works in software system toinvestigate testing and security issues. People with an engineer’smindset want to break down security. Security is a physical problem bynature. You have to analyze the whole thing,” Maxwell toldLinuxInsider.
Overall, code testers found that defect density dropped 16 percentover the past two years. Defect density is the number of defects per1,000 lines of code. For example, a defect density of 1.0 means onedefect in 1,000 lines of code. A defect density of 0.5 means onedefect in 2,000 lines of code.
As many as 314 defects were found in one particular code base. Howoften the same code defect occurs may be directly related to thefrequency of the type of operations the code runs. For example, aNULL Pointer Deference was tracked in 6,448 incidents for 27.95percent frequency. A resource leak occurred in 5,852 defects for afrequency of 25.73 percent.
False positives involved a reasonably small percentage of the results.Currently, false positives are below 14 percent.
Taking Security Seriously
Not everyone involved in building software weighs security factorswith the same intensity. In fact, there is quite a variety of howseriously security is received, according to Maxwell.
For instance, some project leaders restrict access to security staffonly. Others have a wide-open review process. Some projects use hugetests of the software before releasing, he explained.
“When dealing with open source projects, some security issues arehandled free-form. Others are based on maintaining a built-upcommunity reputation,” said Maxwell.
In order to spot defective code that can lead to security issues,those checking the code have to be intent on finding a problem. Manysimilarities in security exist with both open source and proprietarysoftware products.
Engineers who follow one set of standards during their day jobs for proprietary firms might follow those same principles at night whiledeveloping their own software. The major difference stems fromthe case manager who has to follow a set company line, said Maxwell.
“The ‘more eyes’ theory is often valid. More people can participate, butnot all do it. There needs to be enough people with a level ofinterest to look for security flaws,” said Maxwell.
The issue of software security is present on both sides of the softwareindustry — proprietary and open source. However, the amount of testing done and who does it tends to be moremanifest in the open source community.
“[Testing’s] obviously critical, and it’s growing in importance.What’s changed is that testing used to be almost exclusively thedomain of testers who, by definition, aren’t that close to the code. Now,developers are seen to have equal responsibility for security and areexpected to pursue rigorous verification of their code before it’sever given to a test team. That’s a big paradigm shift for manydevelopment teams, but definitely a healthy change where securitybecomes an organizational responsibility and not just the purview ofthe test team,” Gwyn Fisher, CTO of Klocwork, told LinuxInsider.Klocwork develops static code analysis technologyused by software developers and quality assurance (QA) organizations
Security testing should not be the sole approach to getting better codewriting. In fact, security testing should not take the place of goodsecurity-focused design techniques, noted Dave Roberts, vice presidentof strategy for Vyatta. The company develops opensource router and security products.
“It’s easier to design more secure software using a better designmethodology than it is to avoid thinking about security up front andtry to find problems through testing. There are a variety of librariesand tools in common use that make it easier for developers to writesecure software from the start and avoid issues altogether. Thelibraries and tools are not perfect, however, and so you still need tolook for subtle problems once the software is complete, but they doavoid the blatant gaffes,” Roberts told LinuxInsider.
Horse of a Different Color
Security experts still bicker over whether open source or proprietary codeis more secure. The answer depends on some guess work, as well as a measure of religious fervor.
“The honest answer is that nobody knows, and if anybody tells youotherwise, they’re just guessing. There have been some studies thatattempt to characterize one being more secure than another. But mostof those are provided by security vendors with an agenda,” suggestedFisher.
Of course, security is important for both open source and proprietarysoftware. But with proprietary software, there may be a little morecontrol because people can be held accountable, noted Mandeep Khera,CMO for Web application security vendor Cenzic.
“You can also provide security training for your developers, but foropen source, it’s a wild game. You have to be extra careful,” Kheratold LinuxInsider.
However, the more-eyes-on-the-code reasoning carries considerable influence inthe debate. Open source produces more secure software than proprietarydevelopment, proffers Chander Kant, the CEO of Zmanda. Zmanda is an open source backup and recoverysoftware developer.
“The fact that any security issue can be seen by thousands of eyes, infact, makes it easy to find and fix security issues. If you gotproprietary software, just because the security vulnerability may notbe seen in the open doesn’t make the code more secure,” Kant toldLinuxInsider.
No Brainpower Advantage
Asking security experts to debate the merits of security between the species may be missing the point. In fact, Roberts thinksasking which one is more secure is the wrong question, period. Abetter question to ask, he said, is how the community handles thingsonce a problem is discovered. On that one point you see a bigdifference between the open source community and proprietarycompanies.
“There is no reason to think that either open source software orproprietary software is better than the other when it comes to thefundamental development process. While everybody likes to pick onMicrosoft’s security problems on the proprietary side of things, thereality is that developers have intellects that look like a bellcurve. The developers working on open source are no smarter, onaverage, than the proprietary developers, and both sets of developerswill introduce unintended security flaws into the respective codebases,” said Roberts.
All About the Community
The primary distinguishing criteria between proprietary and opensource software is the latter’s commitment to finding, fixing anddiscussing security issues with its user base, Roberts said. There is a sense thatthere is nothing to hide. Problems happen, you fix them, you makeusers aware that a fix exists, and then you move on, he said. Not so for proprietary code.
“The same thing can’t be said of proprietary software manufacturers, onaverage. While proprietary companies are finding that they must getbetter about dealing with security issues, there are many cases wehave seen where the companies will wait months after an exploit isbrought to their attention to develop and adequate fix,” he said.
Other than that, the topic of which software flavor is more secureis oftentimes enough to start quite a heated argument, agreed Sampo Nurmentaus,technical director at Movial. The company developsLinux-based mobile devices.
For him, the openness of open source leads to better, more securesoftware. Open source developers have a totally different attitudetoward the program code.
“An open source developer is like a sculptor that is hired to create astatue to be placed the middle of the city. Since everybody will seeit, it needs to be something he or she can be proud of. This attitudetoward code quality reduces the traditional overflow vulnerabilitiesdramatically,” Nurmentaus told LinuxInsider.