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.

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

Global Response to COSRI 2017 Open Source Security and Risk Analysis

| Apr 21, 2017

Many Black Duck-related news stories in this week’s edition of Open Source Insight, thanks to the release of our 2017 Open Source Security and Risk Analysis detailing significant cross-industry risks related to open source vulnerabilities and license compliance challenges. Black Duck conducts

| MORE >

Open Source 360 Survey, DockerCon 2017, & More on the Cloudera IPO

| Apr 14, 2017

Near the halfway point for April 2017, and the NVD CVE listing for the month stands at 573 entries. Hot this week is CVE-2017-7605, a medium-high vulnerability affecting the HE-AAC+ v2 library (aka libaacplus).   In open source security and cybersecurity news: Take the opportunity to join the Open

| MORE >

Apache Struts Exploits, Cloudera IPO Risks & the Next Cybercon Valley

| Apr 7, 2017

Seven days into the cruelest month and the redesigned NVD already has 255 CVEs listed, including a slew of discovered vulnerabilities in various Huawei devices as the screencap below reflects. It was a relatively slow week in open source security and cybersecurity news. Highlights: The German

| MORE >