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.
Nearly every company writing software uses open source software (OSS) to some degree, but not every company does a good job of governing that usage.
I will begin by defining the two subjects in the above question. “Open-source software (OSS) is computer software with its source code made available and licensed with a license in which the copyright holder provides the rights to study, change and distribute the software to anyone and for any purpose. Open-source software is very often developed in a public, collaborative manner.” (Wikipedia). Open source software exists in everyday technology, like the apps on smartphones, the televisions we use, and even on the complex operating system, Linux. There are hundreds of thousands of open source software packages in existence today.
The title of this post may be a bit misleading. This article is not about how people find open source software (OSS) to use, it’s about how people go about finding OSS used in the applications they develop.
In this exercise, I will demonstrate an approach to converting an Axis2-based web service contained within a web application running on JBoss 7, to a JAX-WS-compliant web service running on the JBossWS framework. For JBoss developers, JBossWS is a great choice for a web services runtime as it is based on the popular, and mature, Apache CXF framework. The Eclipse (Juno) IDE configured with the JBoss Tools 4.0 plugin will be the primary tools used in this effort.
Red Hat and the CentOS community recently announced that the CentOS community has joined with Red Hat to collaborate on future versions of CentOS. Red Hat has hired several members of the CentOS community, as well as added a few new members to the CentOS Governing Board.
In the world of large enterprise, technology infrastructure “procurement” usually includes a lengthy process of evaluating and selecting new goods or services, funding approvals, contract negotiation, and finally purchasing something. Three of these four procurement processes should not relate to enterprises using free and open source software (OSS), correct? So why even consider creating a strategy for procuring open source?
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.