Returning to the Open Source Risk Maturity Model – A New Guide

Returning to the Open Source Risk Maturity Model – A New Guide

In October, I wrote about the four levels of open source risk maturity, a model that organizations can use to evaluate where they stand in terms of the vulnerability and licensing risks they may be exposing themselves to in the course of their use of open source.

To digress for a moment, as this seems to be a point of confusion to some, let me clarify that Black Duck’s position is not that use of open source is inherently risky. But, like all software, open source is susceptible to security vulnerabilities. More than 30,000 open source vulnerabilities have been reported since 2000, with more than 6,000 reported in the last two years alone. Open source also brings with it licensing conditions governing its use and distribution, and organizations that include open source in their code outside the terms of its license are at risk of litigation or worse.

So, the risk isn’t with open source per se. Lack of knowledge about what open source is in your code is the risk. And that is a problem. In our latest survey on the future of open source, it was evident that the development of best-in-class open source security and management practices has not kept pace with its growth.

  • 50 percent of the companies we surveyed have no formal policy for selecting and approving open source code.
  • 47 percent of the companies didn’t have formal processes in place to track open source code, limiting their visibility into their open source and therefore their ability to control it.
  • More than one-third of companies have no process for identifying, tracking or remediating known open source vulnerabilities.

You Can’t Ignore Open Source Risks

You can’t protect yourself against risks that you don’t even know about, but too many organizations are in this dangerous state today when it comes to the open source used in their code. They’re not in this position because they want to be, but because it appears too daunting a challenge to track down and analyze all the open source they have in use and to put policies in place to track vulnerabilities associated with open source.  

In our open source risk maturity model, we term this bottom level as “Ignoring Open Source Risk” although “Unaware of Open Source Risk” or “Tolerating Open Source Risk” would be equally apt terms. However, more and more companies are finding that while they might have the stomach to ignore or tolerate open source risks, their customers aren’t, and those customers want assurance that the software they’re buying has been vetted for open source vulnerability or licensing issues.

Manual Discovery of Open Source Doesn’t Work

Many organizations are aware of the need to to track and manage their use of open source, and have some type of process in place, but unfortunately the results can be haphazard. Some developer teams make an inventory of open source used in their code at the end of the SDLC, often because of external pressures to do so. But identifying and remediating open source issues at that point in the cycle can be a costly undertaking, and with pressure to get the product out the door, problems that should have been fixed can fall through the cracks.

This level in the maturity model we term “Manual Discovery” with cumbersome processes, no one formally in charge of tracking open source usage, and indifferent results in addressing vulnerability or legal issues.

eBook: How Mature is Your Open Source Risk Maturity Model?

Tracking Open Source by Spreadsheet Doesn’t Work Either

Walk into the typical developer group, ask around, and you’ll often be pointed to a group spreadsheet where the coders are supposed to be logging their use of open source, be it components or code snippets.

“Supposed to be” is the key term in that sentence. Except in rare instances, no one is really in charge of that spreadsheet – it’s a group responsibility / requirement that requires consistent developer input to work.  From a coder’s standpoint this third level of the open source risk maturity model, “Tracking by Spreadsheet,” is labor-intensive and time-consuming, wreaking havoc on their productivity goals. From a reality standpoint, using this method rarely produces a full or accurate list of actual open source usage.

Recognizing the Need for Automated Open Source Risk Management

More and more development teams are aware of the license, security, and code quality risks that come with open source and want solutions that help mitigate these risks with minimal disruption of the SDLC. A key problem for organizations at the second or third level of the maturity model is that the current tools they using to track and manage the use of open source are so primitive that any effort to conduct comprehensive open source legal or security audits can be a tremendous drain on resources.

Level four of the open source risk maturity model – “Recognizing the Need for Automating Open Source Risk Management” – is learning how to automate open source detection and inventory, allowing developers to focus on their code rather than on paperwork, and allowing organizations to set and enforce open source use policies very early in the SDLC (when remediation is least disruptive); identify open source license, security, and code quality issues across their codebases; and continuously monitor and report new vulnerabilities, even after applications or containers are deployed.

Advancing Your Level of Open Source Risk Maturity

For those organizations who want to advance their level of open source risk maturity, Black Duck has published a guide, the “Open Source Risk Maturity Model” to help you identify where you stand today with open source vulnerability management, and what techniques you can use to move to a higher level.

 

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

Devil’s Ivy, Bad Taste, & New SambaCry Vulnerability

| Jul 21, 2017

We have two CVEs of the week this week, CVE-2017-9765, better-known as “Devil’s Ivy,” and CVE-2017-11421, dubbed “Bad Taste” by its discoverer. Devil’s Ivy results in remote code execution, and was found in an open source third-party code library from gSOAP. When exploited, it allows an attacker

| MORE >

Black Duck Teams with Google, Connected Cars, FinTech Compliance

| Jul 14, 2017

Black Duck and Google partner so that open source vulnerability management can be integrated directly with build and deployment activities in the cloud. Connected car news includes BMW adding on to its connected car services; concerns on how code vulnerabilities might lead to driving dangers; and

| MORE >

Top Picks for Black Hat, GDPR & Open Source Webinar, UN Cybersecurity Report

| Jul 7, 2017

Our vulnerability of the week is CVE-2017-7526, which resides in the Libgcrypt cryptographic library used by GnuPG. Exploiting the vulnerability, security researchers were able to successfully extract the secret RSA-1024 key to decrypt data. Libgcrypt has released a fix for the issue in Libgcrypt

| MORE >