Given the dominance of open source in the IT marketplace, any significant debate over its value might be considered moot.As Eric Cowperthwaite, vice president, advanced security and strategy at Core Security, told CSO\u00a0recently, \u201cOpen-source code has conquered the world.\u201dIndeed, its advantages are multiple, compelling and well known. Among the most compelling are that it is free, it is open to everybody, users can customize it to fit their needs and there is a community of thousands \u2013 perhaps millions \u2013 of eyes on the code to spot bugs or flaws so they can be fixed quickly, before they are exploited by cybercriminals.[ ALSO ON CSO: The state of open source security ]When the source code is, \u201copen to the world, you are\u00a0going to have\u00a0multiple\u00a0eyes viewing the same configuration,\u201d said Andrew Ostashen, security engineer at Redspin, \u201cso if issues arise, the owners will be able to remediate faster.\u201dStill, world conquerer or not, a number of security and legal experts, while they agree in general with Ostashen and are not issuing blanket condemnations of open source, continue to warn both organizations and individual users that it is not perfect, or even the right fit for everybody.It is critical, they say, to be aware that some of the characteristics that make it so attractive also make it risky. Obviously, if the flaws in code are exposed for all to see, criminals can see them as well. And even millions of eyes on open-source code is not a guarantee that every flaw will be found and fixed.\u201cThere have been claims that open source software is inherently more secure due to the openness and \u2018millions of eyes that can review the source code,\u201d said Rafal Los, director of solutions research at Accuvant. \u201cThis was thoroughly debunked by bugs like Heartbleed and others.\u201d(With) multiple eyes viewing the same configuration, if issues arise, the owners will be able to remediate faster.Andrew Ostashen, security engineer, RedspinIndeed, Kevin McAleavey, cofounder and chief architect of the KNOS Project, somewhat sardonically refers to it as \u201copen sores.\u201d\u201cOpen source publishes the source code, and many eyes claim to review it, thus exposing any possible bad code,\u201d he said. \u201cAnd yet ... Heartbleed. The defective code was right there for those \u2018many eyes\u2019 to spot since its release in February 2012, yet nobody spotted it until more than two years later, after the exploits had become overwhelming.\u201dAnother example he and others cite is the "Ghost" exploit in GNUTLS, which dates back to 2005 but was discovered only last year.\u201cAgain, nobody ever spotted that one either until after exploits were piling up like cordwood,\u201d McAleavey said. \u201cThere was also the \u201cShellshock\u2019 exploit in the BASH shell, which similarly was published, seen by many eyes and dates back to version 1.03 since 1989.\u201dThat is because millions of eyes doesn\u2019t mean all those eyes are qualified to spot flaws.\u201cJust because you have a critical mass of people reviewing the code, are they qualified to do so?\u201d asked Aaron Tantleff, a partner at Foley & Lardner. \u201cThere are no credentials to speak of, or certification that can be given to code reviewed by the open source community.\u201dThat is McAleavey\u2019s view as well. \u201cJust because the source code is there doesn't mean that all of those eyeballs understand what the code actually does, or does incorrectly,\u201d he said.And even if flaws are spotted and patches created, that doesn\u2019t guarantee they will be installed in every device or system that could be affected.Tantleff said recent history is proof. \u201cOne need not look back very far to find examples of the risk of open source in one\u2019s environment,\u201d he said. \u201cPark \u2018n Fly and OneStopParking.com suffered from attacks due to an open-sourced based security vulnerability that existed in the Joomla content management platform.\u201cA security patch had been issued well before the attack, but unfortunately the patch was never installed,\u201d he said.McAleavey, who said he started working with Linux, one of the most popular open-source operating systems, when it came on the scene more than 20 years ago, said this problem exists largely because open source tends to exist as, \u201ctwo separate entities.\u201dIn the case of Linux, \u201cthere is the \u2018kernel team,\u2019 which is the primary operating system itself, and then there are \u2018application maintainers,\u2019\u201d he said.\u201cAny changes to the Linux kernel itself still has to be approved by Linux (creator Linus Torvalds) personally or through one of his handful of trusted kernel maintainers. They, and only they, determine what happens to the core kernel OS itself,\u201d he said.\u201cBut they have no interest whatsoever in what happens among the literally thousands of other open-source developers who maintain a single application or \u2018package\u2019 \u2013 also known as \u2018distros\u2019 or \u2018distributions\u2019 \u2013 of Linux. They're pretty much on their own.\u201dThat, he said, has led to \u201cabsolute anarchy in userland. And that\u2019s not good for stability or security. No one is in charge.\u201dLos said closed-source software is \u201cjust as susceptible to being \u2018abandoned\u2019 as open source,\u201d but noted that the incentive to maintain and update commercial or proprietary software is there, \u201cif the vendor truly cares for their product quality.\u201dBut, like McAleavey, Los said open-source components used in commercial applications, \u201care a massive problem, primarily because they\u2019re forgotten. Take, for instance, the OpenSSL library and the issues that popped up when a series of major flaws were discovered in it. Open-source and commercial software alike fell victim to the dire need to patch, but where OpenSSL was used in commercial applications, many of the end users simply weren\u2019t aware that it was there and so didn\u2019t know it needed to be patched.\u201dTantleff notes the same problem. \u201cJust because a patch exists, doesn\u2019t mean the problem is gone. Someone still has to install it. Generally, there\u2019s no \u2018autoupdate\u2019 for open-sourced applications,\u201d he said.The benefit of customizing or modifying the code to fit the needs of a developer or organization can boomerang as well, he said. All those modifications lead to, \u201cmany modified or forked versions of open sourced programs. Many of those modified applications are re-published for the world to use. The question then becomes which version do you use? Sometimes you cannot tell.\u201dThat, he said, can mean that a user or developer, \u201cthinks he has the patched application, but in reality installed a version that was based on the unpatched application, and the vulnerability remains.\u201dOpen source, pro and conThe benefits:It\u2019s free.Users can customize and\/or modify it without needing permission from anyone.It has potentially millions of eyes working together to spot bugs or flaws.Anyone can fix bugs. There is no need to call the vendor.It is generally just as secure, or even more secure, than proprietary systems.The liabilities:If flaw are exposed, criminals as well as good guys can see them.There is no specific person or entity responsible for patching flaws.When a patch is created and made available, there is no mandate that it be installed.There is no one who will indemnify victims of exploited flaws.If there are legal problems, such as infringement on a third party\u2019s intellectual property, it can be difficult to find another party that is liable.No specific entity or person is responsible for maintaining compliance of open-source software.Open to modification also means it could be open to mischief. Tantleff said the code, \u201ccould be later injected with malware, or worse, specifically written to address an issue that people are seeking open-source applications for, with malware hidden inside from the start \u2013 malware by design. Unfortunately, none of this is theoretical as there are examples of each of these.\u201dFinally, a community of thousands makes it difficult to hold anyone accountable for legal or compliance problems. \u201cIf nobody's in charge, who do you sue?,\u201d asked McAleavey.Of course, defenders of open source say the community surrounding it can be much more dependable than a company with a proprietary system. Writing in CMS Critic, Daniel Threlfall noted that, \u201cif the single company managing the proprietary system goes under, what then? An open-source CMS, on the other hand, has a life of its own. No one entity owns it. Thus, there will always (presumably) be a support network and stable foundation upon which it can exist. The community is the stability.\u201dHow, then, can users get the best out of open source while avoiding the worst?The answer may not be easy, Tantleff said, but it is relatively simple: \u201cCompanies should treat open source like all other software,\u201d he said.It starts with knowing the source. \u201cIt is important that one knows where the software is coming from \u2013 that it\u2019s a trusted source,\u201d he said. \u201cYou should also gather diligence on the software from other trusted sources.\u201dEven if the source is trustworthy, \u201cthey need a proper, controlled process and program for vetting software before deploying it within the enterprise.\u201dFinally, \u201cthey also need a program in place to manage and monitor the software once in the environment, including making sure the organization is aware of vulnerabilities, available patches, and most importantly, ensuring that the patches are installed,\u201d he said.