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.


GDPR Deadline: Does “Appropriate Security” Include Open Source Risk?

| May 25, 2017

It’s May 25th, 2017, and the GDPR is bearing down on us like an express train. Personal data privacy is the impetus behind the EU General Data Protection Regulation (GDPR), which goes into effect in exactly one year — on May 25th, 2018. Will your business be impacted by the GDPR? Any organization

| MORE >

Artifex Ruling, NY Cybersecurity Regs, PATCH Act, & WannaCry News

| May 19, 2017

This week’s news is dominated by fall-out and reaction from last week’s WannaCrypt/WannaCry attacks, of course, but other open source and cybersecurity stories you won’t want to miss include: An important open source ruling that confirms the enforceability of dual licensing. What New York’s new

| MORE >

Protecting Against Ransomware Like WannaCry Means Timely Patching

| May 16, 2017

According to the FBI, ransomware was the fastest-growing malware across all industries in 2016, and is on track to be an $1 billion crime in 2017. The “WannaCry ransomware” (aka “Wana Decrypt0r” “WCrypt” and “WannaCrypt” among ITS various other aliases) has affected an estimated 200,000 computers

| MORE >