Open Source Risks and Responsibilities

The widespread acceptance of open source continues to grow as a cost-effective alternative to traditional network deployments. Well-known projects such as Linux have proven themselves to be in the enterprise environment, helping to dispel the fear, uncertainty and doubt preceding open source implementations. In the past two years, the industry has begun to shift from a total dependence on proprietary applications to a desire for more cost-effective, scalable and collaborative solutions.

IDC has called open source the most significant, all-encompassing and long-term trend that the software industry had seen since the early 1980’s. In their 2006 report, “Open Source in Global Software: Market Impact,” IDC Research found that open source was being used by 71% of worldwide developers and was in production at 54% of their companies. Further bolstering the growing popularity of open source, Gartner Research found in a 2007 report that by 2008, 95% of Global 2000 organizations will have formal open-source acquisition management strategies in place to address the challenges and opportunities of open source software (OSS).

Although open source is not new, it has only recently begun to move past the Linux stereotype in the minds of upper level management. This change in perception is more in line with reality since the major players — “systems” related projects such as Linux OS — account for just 12% of the 151,000 registered open source projects on Sourceforge.net, a repository of open source creativity and development. Although Linux ranks as the open source project that broke through the enterprise adoption barrier, it is clear that lesser known projects are gaining in popularity in terms of usefulness and enterprise readiness, examples include:

  • Mulesource – for integration software
  • Intalio – for Business Process Management (BPM)
  • Pentaho – for Business Intelligence (BI)
  • Groundwork Open Source – for network management
  • MedSphere – for healthcare IT

Open source makes great business sense – it can accelerate time to market, cut down on development costs, is easily adaptable and is free. However, OSS adoption is not without its challenges. Integration and interoperability top the list of enterprise concerns when considering OSS over proprietary applications. To solve these problems, global open source companies have formed organizations dedicated to producing truly interoperable solutions capable of transcending market verticals. The Open Solutions Alliance (OSA), which counts companies such as Unisys, Centric, Spikesource and Jaspersoft among their members, debuted the first open source interoperability project — Common Customer View (CCV) — at the August, 2007 Linuxworld event.

Another example of open source organizations uniting to create standardized solutions is The Collaborative Software Initiative (CSI), a group focused on the development of financial services applications. Though still in their freshman year, these organizations are paving the way for enterprise-ready open source applications.

Open Source Security – Either You Have it or You Don’t
Along with efficiency and cost savings, open source code also introduces new levels of vulnerability and accountability to the enterprise. The sheer size of a code base coupled with the number of contributing developers makes it very difficult for companies to get an accurate assessment of their software assets: What do they have? Where did it come from? What are its intellectual property and security risks?

The FUD surrounding open source has contributed to the myth that OSS is less secure than proprietary software – an oft debated topic. The prevailing opinion amongst the open source community is that OSS is in fact, more secure. Pointing to the thousands of open source contributors on any given project, developers note that any discovered vulnerability is likely to be fixed within hours, whereas a security flaw in a proprietary application may not be fixed for several days depending on the backlog.

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 http://www.gpl-violations.org) 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:
Palamida
Open Solutions Alliance
Collaborative Software Initiative
Eclipse Foundation
Sourceforge
Apache Software Foundation
Ajax

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.

22 Comments

  1. 2007-09-13 3:17 pm
    • 2007-09-13 5:39 pm
  2. 2007-09-13 3:19 pm
  3. 2007-09-13 3:23 pm
    • 2007-09-13 3:42 pm
      • 2007-09-13 4:47 pm
        • 2007-09-13 5:06 pm
          • 2007-09-13 5:47 pm
          • 2007-09-13 5:54 pm
          • 2007-09-13 6:51 pm
          • 2007-09-13 9:16 pm
      • 2007-09-13 4:52 pm
        • 2007-09-13 5:09 pm
          • 2007-09-14 3:21 am
      • 2007-09-13 9:20 pm
  4. 2007-09-13 3:27 pm
  5. 2007-09-13 3:51 pm
    • 2007-09-13 4:59 pm
  6. 2007-09-13 4:48 pm
  7. 2007-09-13 4:56 pm
  8. 2007-09-13 11:14 pm
  9. 2007-09-14 10:10 am