Does Open Source have to mean open to risk?
The acceptance and use of open source as an organic part of the application development lifecycle continues to grow. A 2007 report by Gartner Research states that by 2008, 95% of Global 2000 organisations will have formal open-source acquisition management strategies in place to address the challenges and opportunities of OSS.
The pervasive nature of OSS means that even organisations prohibiting its use in the active development process will have brought it into the network through third-party commercial applications. The use of open source alongside proprietary code is a reality in today’s dynamic application development landscape.
What’s in Your Code?
Despite the laundry list of benefits, the inclusion of open source code in market-ready applications introduces new levels of complexity, vulnerability and accountability to the enterprise. The sheer size of a code base coupled with the number of contributing developers makes it nearly impossible 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?
Although thorough and consistent audits throughout the application development process are critical to ensuring the integrity and security of the finished product, categorising and vetting all of the application components is a time-consuming and error-prone process that makes IP compliance, code vulnerability detection and license management extremely difficult to manage.
In fact, the root cause of many application security vulnerabilities lies in the application source code itself. IDC Senior Analysts Melinda Ballou, Charles Kolodgy, and Melissa Webster wrote in the IDC Insight Report, Driving Effective Security Best Practices and Approaches for Application Lifecycle Management, that enterprises have been slow to demand that their application development groups produce secure software. So long as (insecure) applications can be safely walled off from attack behind perimeter defences, organisations have not been willing to pay the higher costs associated with building secure applications. They note that most application development teams struggle as it is to deliver their projects with all of the intended features and functions on time and within budget without worrying about security. Yet, the necessary rework to repair security vulnerabilities ends up costing organisations both financially and strategically.
When it comes to application development, the development team takes on the role of procurement in bringing open source components into the enterprise environment. Without a proper bill of materials, or thorough understanding of what these components are and where they are located in each application, organisations have no way to know whether or not they are in violation of existing license restrictions or are harbouring known open source vulnerabilities.
Perimeter defences are not able to detect vulnerabilities residing at the code level within the software development lifecycle. Further, while using source code vulnerability detection solutions can identify issues in the coding process they are not equipped to identify open source components and whether or not they contain known vulnerabilities and high-alert license issues.
Thorough risk mitigation calls for more than just firewalls and virus scanning, it requires code level protection against legal, financial and security risks – it requires the detection of software intellectual property challenges and known vulnerabilities in the code base.
What You Don’t Know Can Hurt You
In absence of a robust open source management program, organisations are at risk for a number of legal and security challenges stemming from their software development team which include:
- Unknowingly violating OSS licenses could expose the organisation to termination clauses, injunctions, legal fees and court-ordered fines. It can also result in bad publicity, affecting customer loyalty, partnerships, sales and company valuation.
- Unknowingly shipping products containing components governed by viral licenses which may require companies to provide source code for “proprietary” portions of their product or an injunction 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.
Massive underreporting of actual open source and third party components is a common problem. Ignorance of third-party subcomponent issues (see www.gpl-violations.org) such as whether an apparent BSD licensed product actually contains GPL can cause massive rework of finished products. These oversights can result in embarrassing and costly legal action when found.
There is also the issue of code leakage. A frighteningly common problem arises when organisations mix open source with their proprietary code. As the balance of open source begins to outweigh the internally developed code and projects move amongst many internal development teams, it becomes easy to forget to strip out the proprietary code strings before posting the work 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 organisation’s proprietary code in their code base. Unknowingly, they are exposing their company to legal risk by “stealing.”
Market penetration of open source projects is less mature than the commercial software market although OSS is no less secure. 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 that may be brought in through the development process. Open source projects do not have the same mechanisms in place as their commercial counterparts. They do not automatically push out updates, patches or security alerts. While these things exist for each individual open source project, unless an organisation is aware of what is in the code base, they will not know whether something requires remediation. Further, even if a project contains no current security issues, vulnerabilities may be detected down the line, requiring consistent audits of established software applications inclusive of open source code.
As part of the best business practice for software risk management, companies should create a “golden vault” of approved OSS projects, downloaded from reputable, professionally-run organisations such as Apache, Eclipse, and Ajax among others. Projects outside the established list, such as one-off, anonymous projects with no traceable development history, should be disallowed in the development process, greatly limiting an organisation’s legal and security liabilities and underscoring the integrity of the finished application.
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 organisations 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 the development and legal teams to analyse and prevent open source licensing issues.