Open source is embedded in over 50% of enterprise applications and development environments today yet very few developers are aware of the inherent security risks. What steps should you take to maximize the benefits of open source software while substantially reducing risk?
Security breaches can happen – that’s why it’s more important than ever to understand why secure code matters.
Open source software has become incredibly widespread over the past few years, used by a hugely diverse range of businesses in every sector. Yet there are still a number of areas where open source has yet to be fully embraced. One example of such an arena is securities and derivatives trading.
When discussing the pros and cons of open source software (OSS), most people will immediately list legal or security risks with OSS as huge cons. But the truth is the risks are no different than using commercial software. If you violate a commercial license or if the commercial software you use has a security flaw (and we all know commercial software is full of security issues) than the same could be said about commercial software in general. But the truth is you have to be smart about OSS. You have to understand why it’s important to know where it came from, how it’s licensed, and how to use it to lower your risks, just like you do with commercial software.
Last week we talked about the flaw in OpenSSL known as “Heartbleed” and it’s massive impact on websites and users around the world. We also mentioned how open-source scanning and support tools, such as OpenLogic, report this flaw. Today, we look at how Klocwork handles the issue.
By now, you’ve heard about the OpenSSL flaw that’s capturing the attention of anyone in the world that’s remotely connected with security. Known as “Heartbleed,” this vulnerability allows any enterprising individual to access memory within systems protected by certain versions of the OpenSSL cryptographic library. By accessing memory without authorization, data that you and your end-users care about, such as usernames, passwords, and credit card numbers, are potentially exposed. Given that Netcraft reports that nearly 66% of websites around the world use some form of SSL, this is a seriously bad problem.
It's a given that a successful and sustainable enterprise open source software strategy is going to require some amount of internal expertise. Today’s blog post will outline three options available that technical teams and management are likely to consider before diving in to a new (or existing) open source software initiative. Before we cover the options for improving expertise, a couple questions to socialize internally are:
My previous posts have usually viewed open source in a positive light, but there is a lot that is wrong in the open source community. There is a wide array of issues from legal to security to code quality. This article will dive into some of the issues that surround the open source community.
Note: This blog is a recap of an OpenLogic Webinar held in June of 2013.
Open source software is widely adopted and exists practically everywhere in most corporations and enterprises today. Business departments like marketing and human resources even have a need for and use for many open source tools and free software; and of course developers in corporations are using open source code. This is why many in business today need to be aware of and have a basic understanding of what open source is and what the legal ramifications of its use are.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.