DevOps and Opportunities in Software Supply Chain Governance

February 09, 2017
By Wayne Jackson

4 minute read time

Governance has been an evil word for software developers, but new approaches unlock massive gains in productivity, reductions in cost, and improvements in quality.

These last few years have been a fascinating journey. Concepts that we at Sonatype have been evangelizing for years – component based software development, the proliferation of open source, the inevitability of DevOps – are now becoming widely understood if not accepted. The simple fact is that "software is eating the world" and innovation is driving competitive differentiation in almost every industry, in every market. These advances were inevitable.

Unfortunately, this tectonic shift is not without a downside. Unmanaged use of open source components, for example, can lead to a massive surface area that becomes impossible to maintain (robbing resources from innovation) and high risk from both cyber and operational perspectives.

Leading organizations in verticals such as Banking and Insurance internalized these challenges early and established centralized and highly structured open source governance programs. Typically, these programs consisted of processes by which developers requested permission to use components. Domain experts would then evaluate those requests, including Security, Legal, Architecture and others, who worked toward, most typically, a whitelist of components deemed acceptable for use, often stored in a "golden repository" to be accessed by developers.

Until recently, these approaches represented best practice. Today, these programs are incongruent with modern development practices for four simple reasons:

Time: The typical request to approval time in most organizations that we have talked to ranges from 6 to 12 weeks. Sometimes longer for large projects, shorter for version increments to approved projects.
Conflicting demands: Lengthy approval cycles are not compatible with business demands for innovation, and developers often use creative methods to work around incompatible mandates. One example is a development team that used the components they felt they needed, but renamed them to appear as though they were on the whitelist.
Deterioration: Software ages like milk, not wine. What is perfectly acceptable one day may become enormously risky the next, as new flaws are discovered and new exploit methods are invented. Unfortunately, very few organizations revisit their governance determinations absent meaningful disruption (e.g. Heartbleed, Commons Collection).
Volume: More than 7,000 new projects and 70,000 open source components (versions) are released every week! The interdependencies between these components are nearly incalculable, and the volumes of usage are remarkable – in 2016, we serviced 52 billion component download requests! The simple truth is that the modern software development ecosystem (ecosystems, to be more precise) defies any process that relies on human interpretation as the front line of governance engagement.

So now what? It is becoming increasingly obvious that as we embrace DevOps transformation, we must also embrace governance transformation. Governance transformation should naturally embrace the same concepts that enable successful DevOps initiatives:

Scale: The governance function must operate in the real time flow of the DevOps pipeline. Of course, this is possible only through automation. To automate, organizations must define policies – the attributes of acceptability – that otherwise reflect the considerations applied in manual review. Automation also requires extremely precise metadata and the ability to exactly identify a given component. Not just what the name indicates it should be, but what the internals prove it to be.
Early: Problem discovery, at scale, is relatively valueless in and of itself. To realize its full potential, problems must be identified as early as possible with remediation details that are crisp, detailed, and easily consumed by developers inside the tools they already use. The reduction or elimination of rework is an enormous value driver.
Everywhere: Integrations with automated governance should be in place for the entire DevOps tool chain. There are many opportunities for components to be introduced into a given piece of software. Also, the actions taken related to a given policy violation could, and arguably should, be different, as software applications get closer to production. Once in production, software inventories should be continuously monitored in the context of constantly evolving knowledge about the software supply chain.

Ironically, the organizations that were among the first to understand the challenges of modern software development now have the most entrenched, traditional (manual) governance programs. As challenging as reshaping these programs will be, human-led processes are simply incompatible with DevOps and the goals of continuous delivery. Waterfall concepts and capabilities will still play a role, but not in the native patterns of DevOps processes.

The good news is that for organizations with the will and resources to embrace DevOps and governance transformations, what Gartner has termed DevSecOps, the gains can be enormous. We have started to see customer studies of their own transformation initiatives, and the results are stunning. The most recent I have seen include three industry leading organizations in the Banking, Finance, and Insurance sectors. Their findings:

The elimination of 54,000 hours spent in manual processes (in one organization alone!).
28% (or more) developer productivity gains, mostly driven by faster access to technology and rework reduction.
30% reduction in program costs.
Quality improvements of between 29% and 48%.

Competition has never been more intense for nearly every business in nearly every segment. As challenging as some transitions can be, the rewards for innovation delivery are increasingly obvious and quantitatively measurable. So while historically governance has carried negative connotations (especially for developers), modern software supply chain governance aligns interests, encourages innovation, and enables DevOps to realize its full potential.

Written by Wayne Jackson

Wayne is the CEO of Sonatype, a role he has held since 2010. Prior to Sonatype, Wayne served as the CEO of open source network security pioneer Sourcefire, Inc. (NASDAQ:FIRE), which he guided from fledgling start-up through an IPO in March of 2007, later acquired by Cisco for $2.7 billion. Before Sourcefire, Wayne co-founded Riverbed Technologies, a wireless infrastructure company, and served as its CEO until the sale of the company for more than $1 billion in March of 2000.