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 OSAlert.
“Mark Tolliver is CEO of Palamida, a company that delivers products and services for software risk management.”
The first link at the end of the story is to the contributor’s company/employer. Is this a sales pitch or a commentary?
On the other hand who is better to write about something than a person who works that something for a living.
…but not so much for system engineers and administrators. I can see the mixing of code in a proprietary project being of grave importance and appreciate the author’s warning though.
I understand the problems with OSS projects no longer being updated but for me, when I install an OSS server product, it always comes with it’s own form of update service.
For example, I run Sun’s Java enterprise system which contains many OSS components (Apache and OpenSSH to name but two). When any one of these components get updates, I don’t download the latest source code, I wait for Sun to issue it’s next security patch or fix pack.
The same goes for any Solaris or Linux installation I might be running.
On the other hand, while I was working closely with our internal development team, I found the amount of OSS software used in any given project to be huge. I’m glad none of these projects are ever intended to sold as proprietary software as the sheer cost of replacing all those components would be staggering.
All in all, it’s a good article with some excellent ideas about avoiding code ‘cross pollination’.
Edited 2007-09-13 15:20 UTC
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.
There’s usually a reason for that. For important security flaws, they’ll fix it right away, but they need to do regression testing, determine if the same flaw exists elsewhere, etc. It’s not just a quick hack and they’re happy.
So basically you’re saying OpenBSD is a quick hack?
Huh? Did you misread what I said?
How often has OpenBSD had to fix a serious security hole? How fast did they fix it?
Edited 2007-09-13 16:47
In the default installation? Very seldom. But fixing serious vulnerabilities in their packages (not default installation) ? Constantly. Just because a port isn’t a part of the default installation, doesn’t mean it’s not meant to be fixed
And OpenBSD has so far fixed their holes within hours. It is typical for MOST FLOSS-projects. Security! Security! Security!
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.
It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.
That depends entirely on the application and situation. If the actual loss in productivity due to reduced functionality overshadows the cost of a potential security breach, then you probably want to reconsider. You want to find a balance between ease of use and security, taking into account all surrounding factors.
That is however not a concern of the company behind the product, but merely a concern of those using the product.
1) It is the responsibility of the developers ( or the company/companies) to deliver a fix here and now.
2) It is the responsibility of the users to decide whether or not to install the fix.
If installing the fix breaks the users software and this is more expensive than a security breach, they shouldn’t install the fix. If the security breach is more expensive than reduced functionality, they should install the fix. The developers however only have the responsibility to give the users the choice.
Finding the balance is solely the responsibility of the users.
Keep this in perspective: Packages vs. what’s needed to bring up a system are entirely different concepts.
If someone wrote a program to exploit a hole in the kernel, that’s one thing. If an admin installs an FTPd, for example, they do so knowing that just because it’s made to be compatible with the OS, doesn’t always mean it’s the most up-to-date port when dealing with Free/OpenBSD, which can result in an exploited system if the package goes unchecked – and that’s up to the maintainer at that point.
If the port/package maintainers are lazy, then there’s a HUGE problem. If the original authors are lazy, there’s an even bigger problem with the solution to fork or take over the project somewhere else.
I’ve not meddled with the BSD’s long enough to get into who’s lazy and who isn’t, so I’ll let this one off here, but I will re-state that the differences between OS and other software packages are clearly distinct.
And yes, I get a “Thank you, Captain Obvious” here as well.
What if the fix introduces another security hole? What if it breaks a major feature? I’m sorry, but except in extreme cases (say a worm thats been spreading over the net fast using the exploit), you need to properly test the fix first.
When possible, some companies do provide temporary workarounds until the fix is properly tested and released.
It requires a massive coordination to implement a proper fix.
Who said anything about OpenBSD; proprietary vendors not only have to worry about their own products but products that rely on their own products; they have to ensure that in the process of fixing up a flaw, that in the same process they don’t end up breaking compatibility with something that relies on it.
With that being said, however, I think the issue shouldn’t necessarily be one of ‘excusing’ delays but instead asking why these companies haven’t setup better communication with their partners so that rather than compromising on security fixes for the sake of compatibility, their partners are the first to know about the fix plus what has been fixed so that partners can issue updates for their respective tools at the same time updates are released for the main programme in question.
sappyvcv attacked a specific security policiy of open source projects, and this specific security policy happens to be the security policy of OpenBSD.
So open source projects sponsored by Novell, Redhat, IBM etc. don’t have to worry about the projects depending on them?
And isn’t this also true for open source projects? Or do you claim that no products are based on open source?
Hang on, did you actually read *ALL* the post; did you miss the second paragraph where I actually expanded saying that it could be avoided if the proprietary vendors communicated better each other. Communicated better just as there is good communication between the various open source projects.
I’m not trying to be mean, but do you actually read *ALL* the post before hitting the reply button? honestly – tell me, because I am confused as heck trying to understand how the hell you came to the conclusions that you did.
And for the record, your poor failed attempt to simplify what I said was disingenuous.
I’m urged to comment with ‘Thank you, Captain Obvious!’ to this Article.
Open Source Software and proprietary software have co-existed for about as long as there’s been hardware capable of running it, pre-dating Linux and all the other more recent horses into the race by decades. History shows that there will has always been a combination of the two, and the future is most likely a combination of the two, with neither one completely replacing the other: anyone that states that “OSS will rule the world” is a zealot, as is anyone that states “All software will be proprietary!”
Why will there always be a mixture of both? Because neither one is the whole practical solution for all situations in the real world that also involves budgets, because while OSS and free software may be available for certain things and works best for those needs in a given situation, not all situations have the luxury of being able to afford the biggest resource cost of Open Source/Free software: that of time, with another factor being that of (in many cases) trade secrets/intellectual property being a part of something that needs to remain hidden from the general public and on a need-to-know basis for the entity that needs software to solve a problem. Add to that, there’s many things that are different enough problems from anything readily available that it makes more sense to do a custom project to implement it, and again, there’s the time element: while free/open source software and the ideology is nice in theory and all that, eventually developers need to be paid, because nobody else tends to accept “Well, he’s doing something that he’s not being paid for, so we won’t expect him to pay for our goods and services, either” and as of yet, I’m not aware of any government that pays a developer a stipend for working on any free/Open Source Software, or any other single entity that does. If someone is doing a project on their time outside of regular full-time employment, there’s no practical or logical expectation that they’ll be able to devote nearly as much time or energy to it as a regular full-time job of doing it. Anyone donating their time outside of regular paid full-time employment towards such a project should be thanked for their generous donation of time and energy, and not merely for the time and energy expended for that specific project, but also all the time, money and energy spent studying to become skillful enough to accomplish that goal, which is what a HUGE percentage of people saying, “Do things for free! Produce all this open stuff for us because we want it! Why should you complain?” and those that don’t decide to use up their time, money and energy to do free/Open Source Software outside of what they do for a paycheck should not be harassed, which is all too common.
You make a lot of good points. I would just like to add that I see OSS development more like art than science when it comes to incentives. There are a lot of reasons to do it. Many people get paid to do the programming. You look at the major projects and you will see that the main contributors are working for Novell or Red Hat or IBM or Sun or someone else. Why? Because it gives that company some leverage into how the project moves forward. Then there are the people who write software that is incidental to their jobs. Some system admin needs a tool that does this. He writes it as part of his job and his company allows him to open source it. Then there are the people doing it for free to make a name for themselves. Many students do this to make themselves more attractive to employers. Then there are the people who do it just because the love it. everyone has a different reason for doing it. However, in most cases I would say that there is a underlying truth that they do it more because the love it than because they expect to get paid. This probably accounts for the higher than average quality of OSS software. The only people that I harass are the ones that use OSS and think that using it is all the thanks they need to give.
People like to poke at Apache and other projects – I think one thing people need to realise is this; these projects are developed in the open and under constant scrutiny by end users, developers and detractors alike.
Unlike Microsoft, IBM or any other large software company – these projects don’t have the luxury of being able to hide things when problems are found. Whose to say, for example, that in Microsoft Windows, there aren’t thousands upon thousands of bugs there are confirmed and verified but due to the lack of any motivation by management to allocate resources, these issues simply remain unfixed until such time all heal breaks lose in the case of ‘code read’ and ‘blaster’.
As a company owner, would you rather have full discloser about the possibly risks with your software OR would you rather have a software vendor lie to you about the true status of the software security – and worse still, whose to say that, for example, there isn’t a bitter and jaded employee who decides to disclose those list of vulnerabilities to a group for a set price. It might take a month before this is known by the parent company – and your software might be infected by then. Hardly what I would called ‘secure computing’.
Opensource, as I see it, is like the individual that is too honest; sure, he is honest, everyone knows of his past, but at least you feel secure knowing the full details vs. another individual who is secretive and you never know what he is trying to cook up behind the scenes. You know what you’re getting in the first scenario, its straight up and down honesty. The second, would you really trust them?
Seriously, businesses only trust the money they pay so they can setup requirements and expectations. It’s not about the source or whatsoever. It’s about business people, technical? do they care? After they paid, at least there is SLA they can be based on and blame the company if they don’t meet any single on of the items in SLA. So who do they trust? their money then.
“The widespread acceptance of open source continues to grow as a cost-effective alternative to traditional network deployments.”
I gave up after this first line, can’t contributors be vetted, please?
I mean to differ from this article’s opinion.
He writes, that OSS might pose a risk to a business. I asked myself: What kind of business?
Obviously you do not run any risk if you are a food seller, because even if you use every line of OSS code on earth in-house, there is NO way whow you possibly could breach a license. Even if you adapt the one or other application to better meet your needs.
He is talking about software companies, proprietary software companies to be exact, and they should better stay away from OSS code altogether, or at least evaluate very carefully the license of every piece of code they are going to use. In short words: They should know ho to do their business.
But most proprietary software companies, who ran afoul of an OSS project, deliberately violated the license and knew it (no mercy for them!), or tried to find loopholes in the license (TIVO, NOVELL) and overlooked something.