posted by Mark Tolliver on Thu 13th Sep 2007 08:14 UTC

'Open Source Risks and Responsibilities, Page 2'
Large-scale open source projects (such as Apache) are as secure as any commercial application, which is to say, they will have the same sorts of bugs and vulnerabilities and require ongoing patches and upgrades. Lesser-known open source projects with anonymous developer contributions, unproven track records and suspicious origins, are of course more problematic. Patches and upgrades may be slow in coming, if at all.

While most of the well-known open source projects are inherently secure or rapidly patched, the same does not hold true for lesser-known projects often brought in through the development process. There are many excellent open source applications written by high-achieving college students who, upon graduation, no longer tend to their code.

A bigger challenge when dealing with open source security is patch-management. Commercial applications push out security updates automatically to licensed users and/or Internet-enabled application updates remind us to check for new releases several times per month. Open source software lacks a similar convenience. If you aren't aware of what open source code you're using, how would you know to look for a patch unless you knew about the vulnerabilities in the first place?

With open source applications patch management is similarly complex. The IT department must know which OSS products are installed on the network and would have to put into place a regular, manual, search for the updates -- an onerous process that puts an unwelcome burden on their already limited resources. If IT is unaware that OSS exists, any such performance or security updates will fall by the wayside.

Open source code poses a bigger challenge than complete applications. Buried within millions of lines of code spread across numerous internal and external applications, developer contributions of undocumented open source code leave organizations open to legal, business and security risks such as:

  • Unknowingly violating open source licenses which expose the organization to termination clauses, "stop shipment" injunctions, litigation and court-ordered fines. The resultant bad publicity can affect customer loyalty, partnerships, sales and company valuation.
  • Unknowingly shipping products containing components governed by viral licenses may require companies to provide source code for "proprietary" portions of their product or result in injunctions barring them from future sales of their product until the violation is resolved.
  • Unknowingly shipping dead code as part of the final product, distributing material that is unnecessary and which may incur additional support/maintenance costs on the customer's part if it affects implementation or integration with other applications. Dead code may also include license violations.
  • Underreporting open source and third party components in a company's software assets
  • Ignorance of third-party subcomponent issues (see such as whether an apparent BSD licensed product actually contains GPL can trigger massive rework of finished products.
Code leakage is another problem that arises when open source is mixed with proprietary code -- a common problem with serious implications. As projects move amongst many internal development teams, developers forget to strip out proprietary code strings before posting the work back to open source development communities. These blocks of "open source" code are then picked up by other developers, who now have both open source and another organization's proprietary code in their code base. This scenario creates two problems: inadvertent code leakage and code stealing.

The increase in open source use, and more specifically, Linux, within the enterprise, has attracted the attention of commercial hackers. Largely ignoring OSS due to its previous lack of economic rewards, it is now moving into a place of prominence within global organizations. Criminals can see easy ways in which to capitalize on the available financial opportunities by exploiting open source vulnerabilities with no known patches.

Perimeter defenses such as firewalls, intrusion prevention and detection technologies offer no protection from code level vulnerabilities. Using source code vulnerability detection solutions such as Fortify and Coverity are excellent ways to identify issues in the coding process, they are not equipped to identify code level open source components and whether or not they contain known vulnerabilities and high-alert license issues. These products act as a perfect compliment to software risk management solutions.

It is an accepted fact that application development teams are almost always up against tight deadlines, multiple projects, and a struggle to deliver it all with the intended features and functions, on time and within budget. Built-in security is fairly uncommon, and is virtually non-existent if you're talking about outsourced development. Ironically, leaving open source license and security vulnerabilities undetected leads to sometimes catastrophic rework, costing organizations a great deal both financially and strategically.

Knowing Your Application Ingredients
Today's developers have assumed the role of procurement officers, bringing open source components into the enterprise environment and folding them into corporate software assets. Without a proper bill of materials -- or thorough understanding of what these components are and where they are located in each application -- organizations have no way of knowing whether or not they are in violation of existing license restrictions or are harboring known open source vulnerabilities.

Comprehensive and consistent audits throughout the application lifecycle is critical to ensuring the integrity and security of the finished product, yet categorizing and vetting all of the application components is a time-consuming and error-prone process that makes intellectual property compliance, code vulnerability detection and license management extremely difficult to manage. Companies with established open source software management procedures often track OSS use through a variety of means, using everything from Excel spreadsheets and online inventory lists to sticky notes as audit tools.

Absent a complete list of application ingredients, it can be guaranteed that open source code and its inherent licensing concerns, is going undetected. In software risk management the general rule of thumb is that a code base audit will yield at least 5x more OSS and third party components than a company knew they had. The most commonly found and oft overlooked OSS inside applications include:

  • GNU GetOpt a utility that can be used to retrieve options and option-arguments from a list of parameters. It supports the utility argument syntax guidelines 3 to 10, inclusive, described in the XBD specification, Utility Syntax Guidelines and licensed under GPL v2.
  • GNU GetOpt for parsing command line arguments passed to programs
  • OpenSSH a free version of the SSH connectivity tools that technical users of the Internet are reliant upon. Users of telnet, rlogin, and FTP transmit their unencrypted passwords across the Internet. OpenSSH encrypts all traffic, including passwords, to effectively eliminate eavesdropping, connection hijacking, and other attacks. OpenSSH provides secure tunnelling capabilities and several authentication methods, and supports all SSH protocol versions. It is licensed under BSD.
  • Zlib an abstraction of the DEFLATE compression algorithm used in the gzip file compression program, zlib is a free software/open source, cross-platform data compression library that is something of a de facto standard, to the point that DEFLATE and zlib are often used interchangeably in standards documents. Hundreds of applications for Unix-like operating systems such as Linux, rely on it for compression. It is increasingly being used on other platforms such as MS Windows and the Palm OS. It is licensed under zlib.
The growing complexity of multi-source development environments necessitates transparency in the application development lifecycle. Establishing successful best business practices for software risk management requires organizations to enact generous policies surrounding the use of known open source projects, proactive security audits of open source components throughout various stages of application development, thorough code base scans at each engineering build, and an open line of communication between software development, management and legal to analyze and prevent open source licensing and security issues.

For More Information:
Open Solutions Alliance
Collaborative Software Initiative
Eclipse Foundation
Apache Software Foundation

Mark Tolliver is CEO of Palamida, a company that delivers products and services for software risk management.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Table of contents
  1. 'Open Source Risks and Responsibilities, Page 1'
  2. 'Open Source Risks and Responsibilities, Page 2'
e p (0)    22 Comment(s)

Technology White Papers

See More