Expert guide to open source software security
2 mins read
With two-thirds of IT professionals now using open source software or planning to soon (according to IDG research) – and that it’s on a steep growth curve – Fortify Software suggests that some will get more than they bargained for.
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, says the company.
It cites security expert John Viega: “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.”
Rob Rachwald, director of product marketing at Fortify, says that in fact, the Open Source Vulnerability Database in 2006 showed more than 8,500 vulnerabilities. And the problem, he suggests, is that many open source communities do not utilise security experts, meaning that their security processes tend to be inadequate.
“Are these sufficient reasons to totally avoid open source software,” he asks? “No: the merits of open source 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.”
Fortify recommends adopting the following 10 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.
