We are not the first industry to face this challenge. But many are convinced our problem is much smaller than it really is or that it does not exist. They simply ignore it. Or choose to do nothing about it. Meanwhile, the problem is multiplying like rabbits.
The challenge lies within our software. Within the quality of its supply chain, within our collective ability to maintain its health, and within our ability to establish easy (yes, I said easy) paths to ban rampant, yet avoidable risks.
It is time? It is time for us to evaluate the facts, take account of what we have, and above all communicate? It’s time for full disclosure.
Accepting Our Collective Challenge
Here is our collective challenge: building trusted software applications and keeping them that way over time.
- Over 90% of a typical application is composed of open source components today
- Billions of open source components are downloaded every year to support modern application development practices
- And 58.1 million components with known vulnerabilities were downloaded by developers last year
Adding to those facts, a recent Gartner report states that “by 2016, at least 95% of mainstream IT organizations will leverage open-source technology within their mission-critical IT portfolios — an increase from 75% in 2010.” We are all benefiting from the use of open source components as it speeds our time to market and improves our competitiveness. Yet, we need to realize, there are no free kittens. If we use it, we need to maintain it.
All software we build should be trusted now and over time. Are you ready to accept this challenge?
Taking Account of What We Have
While I am not going to say that your applications include vulnerable open source components, I will say that you can no longer ignore the potential risks. If 58.1 million vulnerable components were downloaded last year across all industries and countries, and there are only 11 million developers worldwide, chances are pretty good that your software development teams and the open source supply chain they really on, is not immune to this discussion.
Let’s keep it simple. We can start by taking account of what open source we have. This includes which components you are using and where those components are being used -- both in development and production. That same Gartner report recommends getting “a precise, instant ‘bill of materials’ of components in use and the related risk levels and license obligations”.
You can use our Application Health Check, to scan your applications for all the open source components so you can have your own “bill of materials”. Its fast, easy and gives you an overview of all the components and any known risks within them.
Want something more? Need instant updates of every component in use across your development and production operations? A living “bill of materials” -- including security, license, and quality related risks -- check out our CLM Dashboard.
But Let's Start with a Strategy First...
Before taking action, there needs to be a strategy for how your organization consumes and maintains its open source components. First, you are going to need an open source policy and an owner responsible for its success. Next, you will need to focus on the right audience for the policy. And lastly, make sure your policy is communicated to all levels and stakeholders across the organization.
But take heed. Modern software development has changed. Manual policies and processes won’t work. Development moves way too fast to be slowed down by outdated, manual enforcement points. So setup your policy to have automation enforce policies and humans manage the exceptions.
Another key to your success? Involving and empowering development. Policy enforcement rooted outside of development within legal teams scanning for license/IP risks or with application security teams bolted-on to the end of the development process are doomed to fail. You don’t want “outsider” strategies trying to control development operations.
Building open source governance into your development operations and involving developers in the process are important aspects to a successful strategy but new rules and tools are always best complemented by communication, communication, and more communication. Even if changes are for everyone’s collective good, change is difficult for some, and communications will help your organization ease adoption and soothe the rough spots.
Perspective Worthwhile
Before wrapping up, let us share perspective from one of our clients, Nigel Simpson, a Director of Architecture in the Media and Entertainment Industry.
Nigel says, "Sonatype is a company with a pragmatic approach to open source governance. They understand that governance requires developers to be engaged in the process for it to be successful. Rather than policing developers and creating obstacles such as audits and approval gates, their software enables developers to make informed decisions about open source that make such strategies redundant. By trusting and enabling developers, compliance is improved and risk is reduced.”
Nigel is not alone in his view of development-centric open source policies and governance. Gartner analyst, Mark Driver, recommends making “developer participation in open source governance processes mandatory”. Mark adds additional perspective, sharing two recommendations:
- Ensure your open-source governance efforts include issues that affect developers, internal and external, because they are often the primary means for many open-source technologies to enter the enterprise.
- Make participation in open-source governance processes mandatory, but avoid cumbersome bureaucratic overhead that overly impedes and restricts developer participation in the process.
It Is Time
It is time for us to evaluate the facts, take account of what we have, and above all communicate? It is time for us all to build trusted software applications and keep them that way over time?
