Stay open to security issues

When you can tinker with the code security becomes a vital consideration, points out Rob Rachwald

Rachwald: Open source deployments require careful consideration of security issues

A recent survey suggested that nearly two-thirds of IT professionals are using open-source software or plan to within the next year.

The benefits to the enterprise are multiple: lower costs, relief on overextended development resources, open standards, rapid deployment and freedom from vendor development schedules.

However, security vulnerabilities may mean that firms are opening their doors to
problems that can adversely affect their businesses, users and customers.

The things that can make open-source programs popular ­ the availability of the source code, and the fact that large numbers of users are available to look for and fix security holes ­ can lull people into a false sense of security.

In fact, the Open Source Vulnerability Database in 2006 counted 8,500
vulnerabilities, an equal number to those listed on the Cert proprietary software
vulnerability database that year.

Many companies accept these risks. The truth is that most open-source software
producers do not make security a priority.

Many open-source communities do not use 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.

There are exceptions, such as Mozilla, but many developers do not consider
security as a separate objective to their standards for overall software quality.

Built-in security has not taken hold widely among open-source developers as they are less likely than in-house or commercial developers to have access to the latest security tools for software development.

Are these sufficient reasons to totally avoid open-source software?

No. The merits of open-source software usually outweigh the down sides, but the enterprise that blindly opens its doors to open-source software without fully judging the security challenges is asking for trouble.

Staying safe
Maintain a software inventory for all applications supported by those within the scope of corporate information security officer responsibility.

Require application inventory records to include component details such as source code location or open-source version.

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

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
pre-production vulnerability scans.

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.

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

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.

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

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

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

Include static analysis in development and dynamic analysis during security
testing in quality assurance.

We have worked with about 100 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.

Because the project is open, potential consumers of open-source software can gauge the level of risk involved in adopting different open-source components and make their choices accordingly.

Rob Rachwald is director of product marketing at Fortify Software