Interview: Palamida on the Risks of Undocumented Source Code

Many companies are beginning to see the intrinsic value of open source software for the enterprise but as businesses piecemeal solutions together from a variety of options, it's easy to lose track of each app's updates and revisions -- leading to potential security issues from unknown or undocumented code. Increasingly, businesses are turning to security companies like Palamida to analyze their in-use source code for security risks and other vulnerabilities. OStatic caught up with Palamida's vice president of product marketing, Theresa Bui-Friday, for insight into why undocumented source code can leave a company at risk for compliance and legal issues.

OStatic: How does so much undocumented code find its way into enterprise software?

Theresa Bui-Friday: Often times, the philosophy of “spend small, think small” prevails for most IT organizations. Unless an organization is adopting a large open source project such as Linux, special resources are not being allotted to the management of open source adoption. Open source means more than just Linux and other commonly used packaged open source enterprise applications (i.e. SugerCRM, Pentaho, Open Office). It is being used up and down the application stack; much of its use is in projects that IT executives have usually never heard of -- utilities embedded inside custom applications for image compression, shopping cart widgets, command line tools, etc.

In today’s world of 24/7 and persistent network access, developers dispersed across multi-national sites can include open source, freeware, public domain, evalware (demos of commercial software), etc, into the code they are writing without triggering the usual checkpoints in the procurement process. Without these controls, the open source is unlikely to be detected, monitored, and tracked. As a result, IT organizations are unaware of exactly what comprises their code base. In 2007, Palamida’s Services team audited between 300M to 500M lines of code for F500 to venture-backed companies, across multiple industries. Of the code we reviewed, Palamida found that applications written within the last five years contain 50% or more open source code, by a line of code count. Of that 50% of open source code, 70% was undocumented. This is up from 30% in 2006.

OStatic:How does Palamida help businesses ensure that their code is safe? What's the actual process? Theresa Bui-Friday: Palamida Enterprise Edition is an end-to-end solution that documents, assesses, and manages open source inventories, associated vulnerabilities, compliance issues, and license concerns within custom-built software applications. By automating the composition analysis of applications, the Palamida Enterprise Edition helps engineering, security, and legal teams manage and secure their use of open source software. Palamida’s software ensures that users can:

• Document Your Open Source Usage: Ensure rapid and accurate analysis of custom-built applications, provide an inventory of open source components and their location within your code base, and report on associated vulnerabilities, license and copyright information.

• Assess Your Exposure to Risk: Provide a reliable framework for security and IP stakeholders to receive alerts of issues as they arise, assess violations against established policies, and document the decisions around remediation.

• Manage Compliance and Collaboration: Assist in establishing procedures, implementing policy and enabling collaboration for approval and/or registry of open source use prior to inclusion within applications.

OStatic: What are some of the things you advise companies to do after you've discovered undocumented code?

Theresa Bui-Friday: It is the responsibility of security and engineering teams to ensure that organizations use processes that produce secure software. Working together, these two departments can effectively insert application security for open source into the overall security strategy by:

Conducting code-level security reviews in addition to penetration tests for their internally developed code before deployment

• Insisting that code-level audits be conducted by outsourced development and business partners

• Ensuring that all other third-party code included in their software applications is identified and tracked for security flaws and updated version information

• Ensuring that internally developed applications have adequate checkpoints that enable thorough audit trails

This means that development organizations must continue to acquire the high level of security expertise required, identify processes for producing secure software, adopt them, and consistently use them when they produce, enhance, maintain, and rework the software that supports a strong application infrastructure.

OStatic: Obviously coders don't intend to produce vulnerable software, so what are the chain of events that lead up to its occurrence?

Theresa Bui-Friday: First it should be stated that open source code is not any more risky or vulnerable than proprietary code. Indeed, it can often be argued that the benefits of “multiple eyeballs” on issues, results in better quality code. What is risky for enterprise is undocumented code (whether open source or commercial). If it’s undocumented, it means that no on has reviewed it for vulnerability issues, no one is monitoring for ongoing vulnerability alerts and no one is identifying whether or not they are on the most current revision.

Today’s software development world is complex and fast-paced, and development organizations are under pressure to deliver large, high quality applications in less time, with fewer resources. As a result, the use of community-based, open source software components has become one of the most dominant trends in software development. The benefits of open source use are clear -- it reduces cost of development and shortens development cycles.

Most Chief Security Officers (CSOs) believe they have adequate application security solutions in place because of significant investment in firewalls, web-based authentication, intrusion detection, and identity management systems. While important security layers, these solutions are securing the perimeter by managing traffic to the applications. None focus on securing the applications from the inside out by hardening application code or managing vulnerability defects.

Based on Palamida research conducted February 29, 2008 - March 4, 2008, examining the support structure for 3,168 popular open source projects, only 1 out of every 10 open source project has a vendor offering commercial support. Almost all the open source projects reviewed do an excellent job at identifying bugs, vulnerability defects, and notifying the community about new patches and versions. However, not many “pushed” that information to their enterprise users, if there was no support contract. As a result, organizations that use open source components are largely “on their own” when it comes to patches, upgrades, vulnerability assessment and similar tasks that are part of a normal commercial service contract. And since much of their open source code goes undocumented, that becomes impossible to do.

OStatic: How can businesses protect themselves -- legally, and technically -- from unsecured code?

Theresa Bui-Friday: Document what you have, identify where it is across your code base, and how much you are using. Assess it for vulnerability defects that could be exploited and for licensing issues that are not in scope with your business model Manage its use ongoing. Once an application is deployed, the responsibility to monitor its use continues, to ensure that no newly discovered vulnerability defects apply to your applications.

OStatic: Assuming a company has measures in place to protect themselves from security breaches, is undocumented code more of a nuisance than a potentially debilitating problem?

Theresa Bui-Friday: Again, open source is not any more risky than any other kind of code. What is risky is not documenting your use of 3rd party code. There are headlines every day that call attention to the fact that organizations should be documenting and managing the composition of their applications, here are some quick examples:

• OpenSSL: Vulnerability inside OpenSSL used embedded in Debian Linux could leave users’ personal data exposed to identity thieves, according to IT consulting group Gartner. The problem is Debian’s implementation of the Secure Sockets Layer communications protocol has made it easy for attackers to discover encryption keys. As part of its market alert on this issue, Gartner Inc. recommended that businesses which use open source software need to adopt vulnerability management processes that include an application inventory to identify “open-source software dependencies” and ensure all current patches have been implemented.

• phpBB: Vulnerability in phpBB, an open source message forum manager, has compromised over half million legitimate web sites allowing hackers to hijack web applications and infect unsuspecting users’ PCs with a variety of malware.

• xt:commerce: xt: commerce is an open source shopping cart utility running e-commerce applications on over 100K servers worldwide There are security flaws in versions earlier than 3.0.4 that allow hackers to trick the ecommerce application into thinking they have credit card information when in fact they have none, rendering the products on those ecommerce apps totally free.

In all of these examples, the open source project community has fixed and posted solutions to the issues. But again, if organizations are unaware of the fact that they are using any of these projects, they cannot take advantage of the resolution.