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.


Equifax, Apache Struts, & CVE-2017-5638 Vulnerability

| Sep 15, 2017

It’s an all Equifax breach/Apache Struts/ CVE-2017-5638 issue of Open Source Insight this week as we examine how an unpatched open source flaw and an apparent lack of diligence exposed sensitive data for over 140 million US consumers. We look at what happened, how you can see if you’ve been

| MORE >

CVE–2017-9805, Equifax Breach & Wacky Open Source Licenses

| Sep 8, 2017

Our vulnerability of the week is CVE-2017-9805, which resides in Apache Struts’ REST plugin, a must-have in almost all Struts enterprise deployments. Attackers can exploit the bug via HTTP requests or via any other socket connection, with a public exploit published on Thursday. Happily, on Monday

| MORE >

Securing Software Stacks, Election Security, FDA Pacemaker Recall

| Sep 1, 2017

News is slight as the US prepares to bore into the Labor Day weekend and the unofficial end of Summer 2017. Yet our crack staff of editors has scoured the Webbernets to produce the best in cybersecurity and open source security news for your reading pleasure. Enjoy, and if you celebrate Labor Day,

| MORE >