How to Standardize Open Source Procurement and Lower Risk (Without Slowing Your Developers)

Open source is the modern development platform — with one recent study showing that 92% of applications contain open source dependencies. Open source is freely downloadable, easy to use, gives developers flexibility and choices — and yet, enterprises are still struggling with a major issue: ensuring that open source components are secure, maintained, and kept up-to-date.

The SolarWinds attack has intensified the importance of understanding how well your software supply chain is being kept up to date and secure. In the fast-paced world of development, security and maintenance questions often get overlooked until after code has moved into production. This puts the business, products, and customers at risk. Because open source code is free to download, it bypasses the normal procurement process enterprises use that are designed to evaluate questions of security, credibility, and standards for vendors the business chooses to trust.

Procurement Is the Missing Link for Open Source

While procurement may be viewed as a painful bureaucracy, it serves a crucial role in enterprises. Procurement helps to standardize the process of bringing in new vendors, ensuring the organization has a single relationship with a vendor (rather than many departments managing their own relationships), and that the organization can get the best pricing and highest possible level of service. It formalizes the commercial relationship so there is a vendor standing by to help when something happens with agreed-upon terms of service and other assurances. Procurement offers peace of mind that helps managers sleep at night.

When it comes to bringing in new software, procurement is usually in charge of things like documenting requirements and success criteria, evaluating the solutions from different vendors, soliciting proposals, choosing providers, and negotiating pricing. In essence, a consistent procurement process helps ensure that good choices are being made about the technology your organization uses.

Yet, open source software has turned the standard procurement process on its head. With traditional proprietary software, procurement is usually brought in upfront to help pick the right vendor and negotiate the best possible deal. But with open source, a free, unsupported component is often already being used before procurement even knows about it. Many don’t even realize that all this open source code is getting deployed.

Why? There is no legal, contractual, or financial barrier to entry to start using open source. Simply type npm install [your shiny new open source package here] and developers are off to the races.

That is, until questions arise when it’s time to start using the component in production:

• Who’s maintaining the code?
• Will they continue to maintain it as long as we need it?
• Who do we contact if something goes wrong?

Open source is a bit like a free kitten. Free to acquire, but once you factor in care and feeding, it isn’t really so free anymore. After adopting an open source component, you’re faced with the following options to maintain it:

1. Your development team assumes the responsibility of keeping it secure and maintained, which takes time away from the important work that is specific to your business.

2. You take the move fast, YOLO approach and assume it is being kept up to date and secure — by someone.

3. You find someone you can pay to stand behind it — which hasn’t always been easy.

For larger, more complex organizations, open source needs a procurement process to prevent risk upfront and ensure the components meet the standards the business requires. But, it also can’t slow developers down.

And, that’s the crux of the issue — how does an organization move fast and stay safe when using open source.

What Would a Procurement Process for Open Source Look Like?

Ideally, a procurement process for open source would preserve its move fast, low friction advantage. What might that process look like? Here are a few alternatives.

The first option is to devote a team of developers to research and recommend open source components that meet a standard set of criteria acceptable to the organization. The evaluation criteria can be developed jointly by a team that includes IT, DevOps, security, risk management and procurement. As open source selections are made, they can be cataloged in a database of “approved” options that developers can refer to when bringing in new code. This list would need to be continually maintained. This is the option used by some of the largest technology companies, but it is an expensive path, so to date, only the biggest companies could afford it.

The second option is to have procurement share their standard list of approval criteria for software and then have developers be individually responsible for going through the checklist before they adopt new open source components. An approval process can be used to document that the criteria have been met. We’ve seen this process adopted by larger organizations with strict security and compliance requirements.

A third option is to utilize a service that helps manage open source for you. With this approach, you offload the labor-intensive work of maintaining and securing your open source to a company for whom this task is job one. This company works with the package maintainers to keep them secure and up to date while ensuring they are licensed in a way that complies with your organization’s standards. This option cuts down on the people and time needed inside the organization to pre-vet open source components before they go into production. This option is best for companies of all sizes who want to simplify and secure their application development pipeline.

Creating an open source procurement process mitigates risk across the enterprise and product lines. With standards in place and questions about security and maintenance answered before developers use the components, enterprises can avoid open source-related risk while still taking advantage of all of the benefits that developing with open source can provide.