Open Source Software Security

(23/02/2009)

Companies everywhere are opening their doors to open source software. A recent survey by IDG of IT professionals revealed that nearly two-thirds were using open source software or planned to within the next year. The benefits to the enterprise are many: Lower costs, relief on overextended development resources, access to cutting-edge technology, freedom from vendor development schedules, open standards and rapid deployment.

OpenLogic reports that in 2006, enterprises on average used 75 different open-source packages and that the number grew to 94 in 2007. But companies can also get more than they bargained for when they choose open source software. Security vulnerabilities in open source could mean that companies are opening their doors to viruses, software exploits and other problems that could adversely affect their businesses, users and customers.

Security expert John Viega wrote in The Myth of Open Source Security, “the very things that can make open source programs secure - the availability of the source code, and the fact that large numbers of users are available to look for and fix security holes - can also lull people into a false sense of security.” In fact, the Open Source Vulnerability Database in 2006 showed more than 8,500 vulnerabilities - an equal number of vulnerabilities when compared to CERT proprietary vulnerability database for the same year.

Is open source software too great a security risk?

Given the advantages to open source software, many companies accept the risks, even if they’re not fully aware of how extensive those risks could be. The truth is that most open source software producers don’t make security a priority in their software development process. They often neglect the three essential elements of security: people, process and technology.

1 - Many open source communities do not utilize security experts
Security is frequently left up to the developer or peer reviews. All too often the attitude is to fix problems that turn up after the release.

2 - Have inadequate security processes
There are exceptions, such as Mozilla, but many developers don’t consider security a goal separate from their standards for overall software quality. The concept of “building security in” has not taken a wide hold among open source developers.

3 - Fail to leverage technology to uncover security vulnerabilities
Open source developers are less likely than in-house or commercial developers to have access to the latest security tools for software development.

What’s a responsible CISO to do?

Are these sufficient reasons to totally avoid open source software? No. The merits of open source software usually outweigh the downsides, but the enterprise that blindly opens its doors to open source software without fully judging the security challenges is asking for trouble.

In the face of these challenges, what is the best course of action for IT professionals to take? Fortify recommends adopting the following ten best practices:

1 - Maintain a software inventory for all applications supported by those within the scope of CISO responsibility. Require application inventory records to include component details including source code location and/or open source version.

2 - Maintain accountability for accurate and complete software component listings by source repository.

3 - Hold open source to the same standard of source code control as software developed in-house. This should include requirements for a documented patch process prior to production use of source code (open or not). It should also require preproduction vulnerability scans.

4 - Where open source fails vulnerability scans, work with developers to see if the vulnerable feature is in use in application software running in house. Also assist in the identification of compensating controls.

5 - Do not allow vulnerable code to run in production without compensating controls.

6 - Train developers on common source code vulnerabilities in such a way that they are directly accountable for any easily identified vulnerability found in their code.

7 - Appoint a security expert with the power to veto releases from getting into production.

8 - Build security in by mandating processes that integrate security proactively throughout the software development lifecycle. Include relevant non-coding activities, such as threat modeling and the development of abuse cases.

9 - Join Fortify’s Open Review Project for the identification of security vulnerabilities in open source software. The review currently supports Java, but other development languages are coming.

10 - Leverage technologies to get security right, which includes static analysis in development and dynamic analysis during security testing in quality assurance.

Fortify has worked with over one hundred open source development teams to identify common security vulnerabilities. The results of these efforts are available to anyone through the Open Review Project. Participants can get full analysis results from Fortify SCA (Source Code Analyzer) and FindBugs and can easily review, comment and act on the findings.

Fortify is exhibiting at Infosecurity Europe 2009, on 28th – 30th April in its new venue Earl’s Court, London, www.infosec.co.uk

Related topics:  Application and software security   Knowledgebase   Security management and policies 

Print version | Email to a friend | Related articles

Data breaches: Trends, costs and best practices gives you all the latest information on securing personal and corporate data, key recommendations for immediate action to improve data security, and how to respond to data breaches.

Other Security news and resources