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 Report Level 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.


Struts Buster Hits Canada, Zero Days, the Best Vuln Info Sources

| Mar 17, 2017

CVE-2017-5638 – the Struts Buster – still leads the news cycle with the Canadian Revenue Agency taken offline to deal with the vulnerability, and Statistics Canada hacked. If you haven’t patched for CVE-2017-5638, go get that update.  The hits keep on coming at the NVD with 657 entries now listed

| MORE >

CVE-2017-5638 Apache Struts 2 Vulnerability & More Security News

| Mar 10, 2017

If you’re running an Apache Struts 2 server and haven’t patched for CVE-2017-5638, stop reading right now and do so. Researchers are reporting that exploits of the vulnerability are trivial to carry out, highly reliable and require no authentication. While NIST has only had a placeholder for the

| MORE >

Open Source Security in SCA, M&A, IoT, & Teddy Bear Cyber Threats

| Mar 3, 2017

February wound down with 1075 CVEs entries total  in the National Vulnerability database.  Before we get into this week’s news, some interesting numbers around software composition analysis (SCA) and open source security via the recently released reports:  The Forrester Wave™: Software Composition

| MORE >