The 4 Levels of the Open Source Risk Maturity Model

The 4 Levels of the Open Source Risk Maturity Model

Where does your organization stand today with open source risk? Where should you be going to effectively secure and manage your open source code? How mature is your open source risk management? Read on to determine where you rank, and where you should be headed.

Get a Free Open Source Vulnerability ReportLevel 1: Ignoring Risk

This level is where organizations are tolerant – or ignorant – of the mingling of open source and proprietary code in their applications and have no open source policies in place to manage the risk associated with their use of open source.

Indicators of this stage include:

  • No policies on open source use
  • No tracking of versions or updates in open source software used
  • No compliance officer or committee
  • No copyright attribution in product documentation

Many organizations are in this dangerous stage today, not because they want to be, but because it may appear too daunting a challenge to track down and analyze all the open source they have in use and continuously track vulnerabilities associated with those open source projects.

Level 2: Manual Discovery of Open Source

Organizations at this level have an inventory of open source that typically is not accurate or doesn’t contain sufficient information. Often there are significantly more open source components in their software code than identified.

Indicators of this stage include:

  • No single responsible entity overseeing open source usage
  • Cumbersome processes
  • Open source inventory typically occurs at the end of the software development lifecycle
  • High effort and low accuracy
  • No ongoing controls

Level 3: Tracking Open Source by Spreadsheet

At this level there is typically a spreadsheet somewhere among the development team's documents that tracks open source components. Developers are expected to document their usage as they add open source components, regularly check for newer versions, and update the spreadsheet as required.

Indicators of this stage include:

  • Requires consistent developer input
  • Labor intensive and time-consuming
  • Difficult to maintain
  • Rarely a full or accurate list of actual open source usage
  • Provides limited insight into ongoing security vulnerabilities

Level 4: Recognizing the Need for Automated Open Source Risk Management

A key problem for organizations at the second or third level of the Open Source Risk Maturity Model is that the tools they have to track and manage the use of open source are so primitive that any effort to conduct comprehensive legal or security audits can be a tremendous drain on resources.

Automation of open source detection and inventory can alleviate this problem, 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.

Indicators of this the need for automated open source risk management include:

  • Development teams are aware of the license, security and code quality risks that come with open source and are interested in solutions that help them mitigate these risks with minimal disruption of the SDLC
  • SAST/DAST tools have been found to not adequately cover open source security risks
  • There is a need to find visibility and solutions that work well within the agile Docker deployment model
  • The organization has a mandate to implement formalized and auditable secure practices into their software development lifecycle
  • Internal and vendor/software supply chain audits

Automated open source software risk management is a relatively new paradigm for many organizations. While they may have a general awareness of the security risks associated with open source, especially given the high public visibility of vulnerabilities such as Heartbleed, most do not have a full sense of their level of exposure and are looking for tools and initiatives that will augment traditional AppSec testing to mitigate potential open source security risks.

Black Duck suggests that organizations first outline a clear vision of what they wish to accomplish with open source management, develop a roadmap and ultimately advance in their open source security maturity. Whatever your level of open source risk maturity, you can look to Black Duck  to help your organization set and use policies to govern open source security, license, and code quality risks, enforce policies and manage remediation efforts. For more information, contact us today.

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.


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 >