Open source software is a significant security risk for corporations that use it because in many cases, the open source community fails to adhere to minimal security best practices, according a study released Monday.

The study, carried out by Fortify Software with help from consultant Larry Suto, evaluated 11 open source software packages and each community's response to security issues over the course of about three months. The goal was to find out if the community for each open source software package was responsive to security questions or vulnerability findings, published security guidelines and maintained a secure development process, for example.

Open source application server Tomcat scored the best in the study, titled "Open Source Study -- How Are Open Source Development Communities Embracing Security Best Practices?"

The remaining 10 open source application, tool and database packages -- Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts -- had a dismal showing. Among these 10 packages, application server JBoss scored higher by providing a prominent link to security information on its Web site and easy access to security experts, but came up short for not having a specific e-mail alias for submission of security vulnerabilities.

"You don't want to report bugs to a general mailing list because it would go to the general public," says Jacob West, manager of Fortify's security research group. There needs to be a measure of confidentiality in reporting bugs so that the fix for them can be provided when the public is notified, so attackers don't get early information they can exploit.

But too often the open source communities that offer their software for free don't appear to be as mindful about security practices as their commercial counterparts, which charge for software and support, West says.

Fortify identified a total of 22,826 cross-site scripting and 15,612 SQL injection issues associated with multiple versions of the 11 open source software packages examined.

But when Fortify tried to reach out to the open-source software communities, with the primary point of contact a Web site and a general e-mail address, the security firm found that "in two-thirds of these cases, you didn't get a response at all," West says. "There are no phone numbers. Who do you go to ask for information? It's kind of hard to tell who these people are."

The report itself notes, "Open source packages often claim enterprise-class capabilities but are not adopting -- or even considering -- industry best practices. Only a few open source development teams are moving in the right direction."

West says Fortify did not conduct this study in order to condemn open source software, but rather to point out that the security practices need to improve because open source adoption by enterprises and governments is growing.

Howard Schmidt, former White House cybersecurity czar who's now a consultant, and also a board member at Fortify, says the study shows that when it comes to business adoption of open source software, "You've got to go into this with your eyes wide open."

The reality is that while open source software may appear more cost-effective and just as functional as commercial software in some instances, the question of maintenance must be examined very carefully.

"Who do you reach out to?" Schmidt asks. "What about the thousands of companies out there running Geronimo? And what about your supply-chain partners?"

The bottom line is that corporations may find they have to undertake remediation of open source packages on their own. "You are effectively on your own, absent your having an arrangement ahead of time," Schmidt says.

Government agencies and corporations need to decide if they're going to try to mitigate problems with open source software themselves, through risk assessment and code review, and whether they plan to give that information back to the open source community.

This is a fundamental question about the life-cycle development of the software, West says, adding that the study indicated to Fortify that the open source communities in these cases tended not to correct for identified flaws in software versions over a period of time.