3 Areas of Open Source Risk: Legal, Security…Do You Know the Third?

Top Three Areas of Open Source Risks: We All Know the First Two

Looking back five or ten years, companies managing open source risk were squarely focused on license risk associated with complying with open source licenses. Beginning in 2014, when open source security vulnerabilities began to get names (like Heartbleed, Shellshock and Poodle), open source security rose in importance as companies addressed vulnerabilities in their code. Black Duck suddenly saw a much broader range of companies interested in controlling open source. Less attention has been paid to a third area: operational risk. Operational risk comprises three elements you need to know about.

Operational Open Source Risks

Black Duck wraps three concepts into operational open source risk: currency of version, version proliferation and project activity. The first, currency of version, is a close cousin to security risk. It simply reflects how far behind the code is on releases of various components. Just like commercial software, good open source projects evolve because contributors from the community (known as “committers" in the open source field) continually improve it. A code base using component versions that go back a few years is not taking advantage of those improvements. Many “improvements” are security fixes, which is why there is a relationship with security risk. Older code tends to be less secure. 

1894.jpgUpdating Components

In a study Black Duck conducted earlier this year, about two-thirds of the 200 code bases we examined contained components with known security vulnerabilities. In nearly every case, those security holes had been plugged in subsequent releases, but components had simply not been updated. Shockingly, the average age of problematic components was more than five years. In fairness, though, a company must be extremely well organized to keep the open source they are using current, because they are typically on their own. There's usually no vendor pushing security patches. Bear in mind, most companies don’t have a record that they are using the component in question.

Version Proliferation

Another operational issue is version proliferation. One bank CIO told me, “I want everyone using Apache Tomcat, but I have discovered at least six different versions across the company.” That’s a nightmare for an organization supporting that software or testing applications to run on it. But again, knowing that most organizations don’t maintain an inventory of open source (even if they have a policy) this consequence is completely understandable.

Project Activity

Project activity is the last element of operational risk. I recently heard a technical due diligence consultant call the problem “stranded code.” What did he mean by stranded code? Use of a component that no one is improving or even maintaining any more. The beauty of an active, vibrant project is that lots of people are working on it, often finding and fixing issues before you even know you have them. And the open source culture is one where these folks will pitch in if you have an issue. About 2,000 developers work together on the Linux kernel in any given year! In contrast, some components began as pet projects, and were abandoned at some point. Developers reliant on those components are on their own to find and fix any issues, which can be difficult for developers who have not been involved with developing the code.

Request a Custom Code Analysis

Consider Your Community

Companies who get the biggest bang out of open source maintain current and consistent versions and ensure that their developers look to use components supported by an active community. But this environment requires some sophistication. Most companies aren’t so sophisticated in their use of open source, which often creates operational risk. If you are buying a company , you need to work some remediation of open source risk into your calculus.

Black Duck’s products help companies track and manage all three kinds of risks. And our audits can quickly pinpoint the risks on a one time basis, for example to evaluate an M&A transaction. But we also offer valuable risk information on hundreds of thousands of components for free in the Black Duck Open Hub. Check out your favorite projects there and you will find the license, security ratings, version information and activity metrics. Simply sending your developers to the Open Hub to do their diligence before selecting a component will go a long way to avoiding future risks. 

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Diving Deep into Wild & Wacky Open Source Licenses

| Sep 5, 2017

Copyleft terms seemed pretty strange to many seasoned attorneys familiar with commercial software licenses when they first encountered the GPL, but it is far from the weirdest license out there. The GPL-2.0 remains the most popular license and the choice for millions of open source components

| MORE >

The Quietly Accelerating Adoption of the AGPL

| Aug 14, 2017

The AGPL (Affero General Public License) has continued to gain in popularity and is showing up frequently in modern code bases. My blog Are SaaS Companies Immune to Open Source Risk? mentioned a key concern for SaaS or Cloud companies, a class of open source licenses that includes the Affero GPL

| MORE >

Can Blockchain and the BTC License Fund Health Insurance?

| Jul 26, 2017

The BTC license hit my radar screen recently. Billed as “sexy” by the author, the permissive BTC license employs Blockchain and may signal a new trend going forward that could transform the way many developers work... and how they get their health insurance. Background I chair the Linux

| MORE >