Black Duck Blog

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com
Definitively knowing what encryption is in use lowers security risk

On February 16, Version 2.0 of the CWE/SANS Top 25 Most Dangerous Programming Errors was released. The Top 25, developed collaboratively by more than 30 cyber security organizations, are the most widespread and critical errors that lead to serious software security vulnerabilities and attacks.

“Use of a Broken or Risky Cryptographic Algorithm” (CWE-327) made the list, coming in at #24. Many companies unwittingly and unnecessarily expose themselves to this risk, which could result in the disclosure of sensitive information.

To avoid such a risk, the CWE/SANS report authors recommend the following:
• “Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations.”
• “Periodically ensure that you aren’t using obsolete cryptography.”
• “Automated methods may be useful for recognizing commonly-used [cryptography] libraries or features that have become obsolete.”

For those of you familiar with us, one of the key capabilities in Black Duck Export is scanning for and detecting cryptography in code. While one use of Export is ensuring compliance with government export controls surrounding encryption, a key part of this is to detect which crypto is in use. Using our technology, Black Duck conducted a study of its own revealing encryption algorithms widely embedded in open source software.

The CWE/SANS recommendations do work. On multiple occasions we have heard from Black Duck customers who have discovered, to their surprise, that the encryption algorithms they were actually using was much weaker than they intended.

According to the Ponemon Institute’s most recent U.S. Cost of a Data Breach Study, the cost of data breach incidents to U.S. companies is on the rise. The average total per-incident costs in 2009 were $6.75 million, compared to an average per-incident cost of $6.65 million in 2008.

Another good reason to make sure you know your code so that your software development teams and your organization can have the peace of mind to focus on your top business objectives.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com
In a recent Back Duck survey, we found that companies doing software development are using significant amounts of open source software; about 22% of code was identified as originating from an OSS project.

The cost savings from strategic use of open source can free up precious software development resources and compress project schedules. To calculate how much, see the Black Duck ROI calculator.

Many developers and managers have anonymously used this calculator to help with the decision of whether to reuse existing software or write a software component from scratch. The calculator allows one to enter assumptions for different factors that affect this decision. For example, the average value input for the cost of a software developer was $79,000. This value varies by company and region. When companies compute the cost of a developer, they start with salary but add in other costs as well: benefits, overhead such as utilities and administration, and expenses such as dev tools and hardware. These costs typically add a significant uplift on top of salary. When the Linux Foundation published an estimation of the cost of developing Linux, they called this uplift the “wrap rate” and fixed it at 2.4 times salary. This figure originated from a well-known study by David Wheeler. With that in mind, the figure of $79,000 either represents salary only or reflects a lower cost region of the world not the major business centers in Europe and North America.

Additionally, people input 16,000 as the average number of finished lines of code produced by a developer in a year. This number happens to be much different than we would have expected. When you include architecture, design, debugging, QA, compliance and administration, the number of fully, tested, vetted code tends to be much less. The Software Engineering Institute at Carnegie Mellon, estimated this value at about 20 lines of code per day (~4440 per year). Developers may not have been considering these other costs when using the calculator so the 16,000 figure probably reflects just the creation of new code.

With these caveats in mind we can start to look at the compelling economics of using open source. The average size application input was 363K lines of code. At the average level of salary and developer productivity noted above, it requires 22 developer years or $1.8M USD to create a 363 thousand line application from scratch.

Phil Odence
Vice President of Business Development
podence@blackducksoftware.com
I was recently talking to prospect who was digging very deeply into how hard it would be for his developers to “game” Protex, i.e. get some open source code and modify it to the point that it would not be found in a scan. In the end, he was convinced that the analysis performed by Protex is sufficiently sophisticated that gaming the system isn’t worth it. Fooling the tool requires as much work as writing the code from scratch. However to me, the bigger issue is a fundamental belief that given the chance people will generally try to do the right thing.

Of course that can all fall apart under stress. About the time I was having the above conversation, NPR started reporting on the rampant break-ins and looting in Port au Prince. They got a backlash of reactions from their listenership who essentially took the position, “What the heck do you expect?” Yes, it’s understandable when people under stress break the rules and take what isn’t theirs.

Software developers today are all under great pressure to do more, quicker with less. Utilizing open source components is a great way out of this rock/hardplace position, so it’s no surprise that most developers today are making heavy use of open source. It is incumbent upon companies to provide their developers guidance (in the form of open source policies) and streamlined processes for managing their use of open source. Without guidance, the risk is that developers will not look beyond technical capabilities when selecting components. Or, in the other extreme, faced with a cumbersome approval process and under great schedule pressure, even God-fearing developers will look for ways around it.

There’s a great competitive advantage for companies that embrace the use of open source components. Those that provide policies to guide their developers and automate the processes for selecting, tracking and approving components will find their developers pleased to be more productive and doing the right thing.

Timothy Kenny
Director of Marketing
Tkenny@blackducksoftware.com
Everybody knows open source software is free, and many know it has other significant benefits for developers in productivity and enabling innovation, but there is no free lunch, as open source components are not free of obligations. Obligations around making enhancements available, attribution, use, the list goes on and your free lunch starts giving you indigestion.

A recent survey by the 451 Group found that 58% of companies surveyed do not have formal polices or guidelines for using open source. Recently, Artifex, which uses a “dual licensing” model (providing the software under both the General Public License (”GPL”) and a commercial license) for its MuPDF rendering engine, filed suit against Palm for alleged copyright infringement. This is the first lawsuit by a commercial open source vendor, which is said to be signaling a trend towards more litigation this year. With hundreds of thousands of open source projects available to date, coming to grips with the challenges associated with using open source can be difficult for the uninitiated.

The reason for this high percentage can be attributed to the fact that many companies never fully cover the basics of using open source software with their employees. On this topic Karen Copenhaver partner at Choate Hall & Stewart and Counsel for the Linux Foundation recently teamed up with Mark Radcliffe, partner at DLA Piper and General Counsel for the Open Source Initiative, to present a webinar on the basics of open source software, which covered open source definitions and the different types of licenses.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com
There are many consulting firms that earn a living on the fear, uncertainty and doubt associated with the failure of IT projects. It’s not hard to find statistics warning of the many risks inherent in new software product or application development. Here are three of many examples:

• A market survey cited by CIO.com reports that 62 percent of IT projects fail to meet their schedules.
• IAG writes that “68% of companies are more likely to have a marginal project or outright failure than a success.”
• Standish Group’s well known Chaos Report describes over 80% of IT projects as being “challenged” or “cancelled.”

According to these oft-cited studies, it may be more of a surprise when a development project actually goes right.

I was pleased to see a recent 451 Group survey showing that 87.2% of 1,711 IT professionals, rated open source software as “meeting or exceeding financial-benefit” expectations. This comes as little surprise to those of us that work with and around open source. The increase in OSS adoption has been slowly and steadily on the rise – supported by the tough economy which has significantly pressured IT and engineering budgets. 451 Group further writes that 46.5% of those surveyed are more likely to adopt open source as a result of the current economic climate. This market transformation has driven robust demand for solutions like the Black Duck Suite which just finished another record year.  If properly managed from a risk and compliance perspective, the productivity and cost benefits of open source can be significant. My take on the 451 Group report is that strategic use of open source is being widely used to lower costs. In an environment where a majority of IT projects are delivered late and over budget, it’s nice to have a high probability success in the mix.