Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Open source code contains fewer defects, but there's a catch

Paul Rubens | Nov. 19, 2014
Research suggests that software developed using open source code contains fewer defects than that built with proprietary code. The catch is that open source code rarely benefits from security teams specifically tasked with looking for bugs.

"A typical proprietary software company will have a security team that ensures that best practices are carried out. They have the budgets to maintain those teams," he says. "I don't see those entities ... in the open source community."

That may be true of smaller projects, but commercial open source companies such as Red Hat, along with many large open source projects -- especially those with software intended for enterprise deployment -- almost always have a concerted security effort.

Samocha says the Linux community is taking steps to increase security -- although more needs to be done, in his opinion -- but adds that all open source projects need to add security to their day to day thinking. "In commercial software companies, developers and CIOs think about security all the time. In open source projects, I'm not sure that that happens."

Samocha also believes that open source projects could better use the ecosystem around security, and the commercial tools that exist. "The majority of tools are aimed at security teams rather than developers," he says. "Security teams should be filtering the defects and giving relevant ones to the developer community to fix."

Static Analysis Tools Help, But Only to a Point
Of course, projects that don't have a security team can't work in this way. Individual developers who run analysis tools risk being swamped by too many irrelevant bugs or false positives. This may lead them to ignore these tools altogether.

"If developers have to waste precious cycles investigating too many 'don't care' findings, or if they spend too much time waiting for the analysis to finish, they will inevitably stop using those tools," says Jon Jarboe, a senior technical manager at Coverity.

Security teams also prove useful because, while running code through static analysis tools can spot many code defects, it certainly won't catch them all.

The Heartbleed bug is a good case in point: At the time, Coverity's static analysis wouldn't have detected it before it was discovered. (The company has added a new analysis heuristic that does now detect it, but that's beside the point.) The Shellshock bug is another: Some static analysis tools would have spotted it, but only along with a large number of issues that would have turned out to be false positives.

"Static analysis can find known vulnerabilities. What about the unknown vulnerabilities?" asks Mike Gualtieri, a principal analyst at Forrester Research. "That's where threat modeling comes in. This technique allows you to find the threats to your application and to identify mitigation strategies for each of these threats."

When in Doubt, Audit Your Code
Such a holistic approach to security may be difficult to achieve in a project with many contributors and no security team to coordinate it. How, then, can the level of confidence in open source software be improved?


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.