As Marc Andreessen famously observed, "software is eating the world." The proliferation of software is, indeed, transformational – it is everywhere, in laptops, of course, but also in cars, planes, phones, pacemakers, insulin pumps, refrigerators, thermostats, you name it. And the principal enabling transformation behind that is open source.
When polled earlier this year, 86% of software developers said that at least 80% of their applications were these open source building blocks (that run with the full privilege of the application). Most believe the ratio to be on the order of 90% components to 10% code, the inverse of the ratio of just 10 years ago.
Well there's certainly nothing wrong with benefiting from the collective brainpower of millions of software developers, but who, exactly, are these developers? The truth is that, for the most part, we don't know. The ecosystem is, in many ways, the Wild Wild West where the (perceived) merit of one's contributions is the only thing that matters. Open source is, perhaps, the largest geographically indifferent meritocracy ever.
A little background…
In 2001, Jason van Zyl, a frustrated engineer with an obsession for order and efficiency, created a software build management system called Maven. Maven was revolutionary mostly because it made reusing other people's software inventions really, really easy. Rather than having to figure out how to integrate someone else's source code (not to mention all of the "stuff" on which their code relied), and then figure out how to compile all of that into a binary, Maven enabled developers to leverage external innovation in binary form directly.
Enabling developers to move away from a code-centric model where software was written (or copied) to one where software is largely assembled (think Legos) has led to remarkable advances in the speed and efficiency of software development. The degree to which this advance in leveraged innovation has changed our world cannot be overstated.
As most folks in the developer realm know, Sonatype is the caretaker of Maven Central, the world's predominant distribution point for these open source building blocks (aka, artifacts, binaries, or more simply components). To give you a sense of trajectory, seven years ago Central was serving components at the rate of 100 million or so per year. In 2013, we served more than 13 billion components.
So…
In the context of enormous pressures to deliver, what's not to like about dramatically more speed, innovation, and efficiency (and did I mention speed)?
Given the frequency of coding errors and ease with which malware can be injected into a given piece of software that looks like a simple coding error (even to a skilled auditor), my belief is that they should. And as they realize that, in essence, millions of strangers can change the code that lives in their data center, I'm guessing they will.
So how do we deal with what might be the largest supply chain risk management problem in history? How can we learn from other industries, for example, the automobile industry, which is capable of recalling and remediating flawed automobile components with remarkable efficiency?
What are the things that we, as a community, should be doing to better assure that each step in the lifecycle of open source, from conception to consumption is as sound as it could or should be?
As a starting point, we would like to propose three goals as part of an effort to reduce supply chain risk:
-
Create a project, platform, and language agnostic scoring system for measuring project integrity. Measures might be classified in terms of project maturity, license discipline, vulnerability mitigation, and the integrity of their role in the supply chain (the integrity in the flow of contributions from committer, to project, to Central, to the developer)
-
Establish a framework for the scoring system that enables every interested party to completely understand the scoring system and normalize that system across a large set of platforms, languages, frameworks, etc.
-
Develop a system to manage and mitigate open source risk that can by embraced by the community and integrated into normal community practices. And make it easy to do so.
Ultimately, the goals are increased visibility and transparency, components that can be used with a high degree of confidence, and an ability to score applications themselves based on clear and understandable supply chain integrity measures.
We do not, though, want to do this work in a vacuum. We all need the benefit of open source to significantly outweigh the risks. Over the coming months we will be working with thought leaders in the open source community and others in the industry focused on software assurance and supply chain risk management.
We'd love your help as we begin to really dig in.
In the mean time though, you ought to wonder… where exactly did all the code behind all of these open source components really come from?
Disclaimer: I am a firm believer in the enormous value that the open source software ecosystem has unlocked, ushering in an era of unprecedented development productivity by making it easy for everyone to stand on the shoulders of giants. Sometimes, though, it's worth noting that there is an elephant in the room, and then doing something about it.
