Breaking Bad: How Good OSS Components “Go Bad”

Author, Matthew Barker

Breaking Bad OSS

Living in Albuquerque, NM, of course I got into Breaking Bad, it’s a compelling story of how even the best intentioned people can “break bad” – it does remind me of how even the best intentioned organizations attempting to use only secure versions of components in their applications still fall short of their goal and newly discovered risky components are lurking in their applications with zero awareness of their vulnerabilities.

The Old [Watch]Dog

Many organizations are doing their due diligence to research their use of these components even to the point of pre-approval of OSS component usage or locking down their OSS repository — a so called “Golden Repository” approach. What most of these organizations fail to realize is that good components often “break bad” and their so-called “Golden Repository” will quickly be littered with some very bad dudes and even worse, many of these bad guys will already be in your applications.

And while we can’t prevent components from breaking bad, when they do, there are often safer versions available for us to use. The question then becomes, how do we quickly identify those that go bad while also identifying safer alternatives?

New Tricks

So how can one monitor our use of OSS components when there are often thousands of these components in an average organization’s applications and new ones being added on a daily basis? Automation is the only solution that scales and Sonatype’s CLM (Component Life Cycle Management) provides automatic OSS governance across your entire software life cycle particularly after an application is released for those components that inevitably “break bad”. In this case, governance not only includes quickly identifying components that have gone bad, but identifying safer alternatives for you to use that can help mitigate the risk.

Your DEA Task Force

Think of CLM as a perfect worldwide DEA-for-components task force that monitors all reports of “bad” components and immediately alerts all organizations using a new “bad” component within hours after security vulnerability is reported (via an e-mail group).

CLM-for-DEA

How does the Sonatype CLM OSS task force work?

  1. Digitized and Automated Policies:  Custom policies tailored to the type of application are created that defines the level of risk that your organization is willing to tolerate in your use of oss components.  For example a consumer facing web application might have stricter policies in place than an internal application accessible only by employees.  One of the CLM template policy sets will give you a head start on defining your custom policy set – no need to re-invent the wheel.  Once developed, these policies are automatically enforced across your entire software life cycle – develop, build, test, release, and even post release.
  2.  Continuous SDLC Governance: Automated CLM application scans prior to release ensure that all components in your released applications are free of known security risks as defined by your custom policy set.  This provides the baseline needed by CLM to identify newly discovered vulnerabilities.
  3. Improved Decision Support: Sonatype’s expert security team monitors vulnerability reports from the National Vulnerability Database, the Open Source Vulnerability Database, and other sources.  Their expert security team curates these alerts finding the complete list of affected components even including components not listed in the initial alert – think of this as finding an entire gang of bad guys, not just the one’s initially reported to be bad.
  4. Continuous Visibility: With continuous visibility enabled, any newly discovered bad components (as defined by your custom policy set) in any of your organizations released applications triggers e-mail alerts to be sent to one or more interested parties from your organization – this monitoring is done on a daily basis for prompt, accurate monitoring of all your OSS components in all of your applications.

Breaking Bad brought home the point that even good people can “break bad”, it’s true of people and it’s certainly true of components. Automated continuous governance of and an easy remediation path for OSS components used in your released applications is the only way to ensure your applications don’t break bad and become the vehicle for a serious breach.

If you are a Breaking Bad fan, you could consider Sonatype CLM to be the DEA’s continuous monitoring task force for your breaking bad components.

The following two tabs change content below.

Matthew Barker

As a experienced Solutions Architect and Sales Engineer, I help companies efficiently secure their applications. My broad-based experience in open source software and rapid application development combined with my background in software security enables me to provide insightful, technical guidance to companies desiring to produce secure applications of high quality and with minimal license risk.
Authors

Related posts

*

Top