Tantleff notes the same problem. “Just because a patch exists, doesn’t mean the problem is gone. Someone still has to install it. Generally, there’s no ‘autoupdate’ for open-sourced applications,” he said.
Benefit boomerang
The benefit of customising or modifying the code to fit the needs of a developer or organisation can boomerang as well, he said. All those modifications lead to, “many 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.”
That, he said, can mean that a user or developer, “thinks he has the patched application, but in reality installed a version that was based on the unpatched application, and the vulnerability remains.”
Open to modification also means it could be open to mischief. Tantleff said the code, “could 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 – malware by design. Unfortunately, none of this is theoretical as there are examples of each of these.”
Who to sue
Finally, a community of thousands makes it difficult to hold anyone accountable for legal or compliance problems. “If nobody’s in charge, who do you sue?,” 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, “if 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.”
How, 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: “Companies should treat open source like all other software,” he said.
It starts with knowing the source. “It is important that one knows where the software is coming from – that it’s a trusted source,” he said. “You should also gather diligence on the software from other trusted sources.”
Even if the source is trustworthy, “they need a proper, controlled process and program for vetting software before deploying it within the enterprise.”
Finally, “they also need a programme in place to manage and monitor the software once in the environment, including making sure the organisation is aware of vulnerabilities, available patches, and most importantly, ensuring that the patches are installed,” he said.
Taylor Armerding, IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers