Automated Enforcement: The Not So Subtle Difference Between Sonatype Nexus and Everyone Else

We live in an application economy. Software has become the strategic weapon of choice for competing and winning on a global playing field.  This is a world where innovation is king, speed is critical, and open source is center stage.

To compete effectively, companies aren’t just writing software — they’re embracing DevOps to manufacture apps using an infinite supply of open source component parts, machine automation, and supply chain-like processes.

Operating in this environment isn't easy. Thus, organizations are seeking tools to integrate open source governance into every phase of the DevOps pipeline and automatically control how components flow across the entire development lifecycle.

See the Similarities; Celebrate the Differences.

As more teams shift from waterfall-native to DevOps-native development, Sonatype and our competitors are using similar words to describe (a) the ability to integrate with existing pipeline tools, and (b) the ability to automatically enforce open source policies across the modern development lifecycle.

So what's the difference between these solutions? Why is Sonatype Nexus better than the competitors?

The answer is simple: automated enforcement.

Only Sonatype Nexus delivers open source intelligence that is precise and accurate enough to enable machine automated enforcement of policies across every phase of the modern DevOps pipeline.

Obviously, I work for Sonatype and my opinions are admittedly biased. So, rather than take my word for it, I respectfully ask two things: (1) read the rest of this post with an open mind, and (2) evaluate the Nexus platform head-to-head against the competition and see for yourself the not-so-subtle differences.

The Path to Automated Enforcement is Informed by History

A decade ago, spurred by the GPL lawsuits, organizations began to take steps to govern how open source components were being used by their development teams. At first, they created simple "whitelists" and "blacklists" and looked for tools to help enforce compliance.

In response to this demand, Sonatype introduced the "Procurement Suite" within the popular Nexus Repository Manager. Feedback from enterprise customers allowed us to see first hand the significant limitations associated with a blunt "list based" governance solution. Specifically, we learned that enforcing policy at a single point in the value chain is a "black and white" approach to a problem that demands "shades of gray" subtlety and context. Indeed, no two applications are the same -- and therefore governance solutions must be flexible and contextual. For example, what if you want to allow a particular component to enter into dev while more detailed assessment is performed, but prevent it from ever releasing into production without final approval?

Years later, disasters like Heartbleed introduced a whole new element into the requirements for automation. Whereas component licensing is largely static; component security is highly dynamic because new vulnerabilities are frequently discovered in components that were previously thought to be "good". The quicksand-like nature of security vulnerabilities illuminated the impossible challenge of maintaining "whitelists" and "blacklists" and emphasized the need for automated systems to inform real time intelligence for open source governance.

The Path to Automated Enforcement is Paved with Precise Data

Our rich history and past experience enabled us to grasp the fundamental connection between "precise" component intelligence and "automated enforcement" of open source policies. This perspective allowed us to deeply internalize the difference between "problem discovery" and "problem remediation".

In the past, we saw waterfall-native organizations using "problem discovery" tools to scan open source components as part of an asynchronous QA process. We saw application security teams within these same organizations readily tolerating "false positives" and manually digesting them with teams of highly compensated humans before sending things back to dev for rework.

Recently, with the dawn of DevOps, we saw these same organizations aspiring to new levels of efficiency and automation. Application security and dev teams alike became intolerant of "bad data" and "false positives" and began seeking contextual and truly automated enforcement of open source policies. At the end of the day, DevOps automation is not for the faint of heart. If you're going to do it right, then you need to trust that your tools are precise enough to automate policy enforcement actions such as "breaking builds" or "blocking releases".

The Path to Automated Enforcement Spans the Entire Pipeline

Very similar to a physical goods supply chain, the DevOps pipeline is broad and consists of many different tools, processes, and constituents. Every vendor of open source governance solutions touts their ability to integrate with a wide variety of pipeline tools for purposes of automating policy at different points along the lifecycle.

As you examine different governance solutions, it is critical that you clarify: what exactly is being automated? Is the tool automating the process by which open source components are scanned and reports are generated? Or, does the tool actually automate governance controls and enforcement of policies? Ultimately, any tool that fails to automate active enforcement inside of the pipeline will NOT scale and NOT add value.

Seeing is Believing

Automating enforcement of open source policies is increasingly table stakes for DevOps native dev teams. Unless your solution actively enforces open source policy controls -- being integrated across the DevOps pipeline is irrelevant. Furthermore, if your underlying component intelligence is not precise enough to trust -- then you will NEVER be able to automate and scale your open source governance program.

Schedule your demo of the Nexus platform today. Evaluate it head-to-head against the competitors and see for yourself the not so subtle differences.