OSPO security evolution: The Kübler-Ross Model of open source

What’s in an OSPO? Open Source Program Offices are popping up all over, in recognition of the facts on the ground: open source software (and I would argue open standards as well) plays an enormous role in building and maintaining the software that increasingly drives the planet. The Linux Foundations’ The Evolution of the Open Source Program Office (OSPO) report talks about five stages of development of an OSPO:

• Stage 0: Adopting Open Source Ad Hoc

• Stage 1: Providing OSS Compliance, Inventory, and Developer Education

• Stage 2: Evangelizing OSS Use and  Ecosystem Participation

• Stage 3: Hosting OSS Projects and Growing Communities

• Stage 4: Becoming a Strategic Decision-Making Partner

 But when it comes to security, it might be more instructive to think about the different five stages (à la the Kübler-Ross Model):

• Denial: Organizations are in denial about the extent to which they depend on open source. They may think they know but when they actually start thinking about it they realize how fully leveraged they are on a range of open source code and open source tools, especially in the build pipeline. You can check the 2022 Snyk Open Source Security Report for the same. 

• Anger: Since they haven’t been paying attention, organizations don’t even know how much open source code they’re using. This anger (hopefully) leads them into a frenzy of education and accounting for open source projects and into a greater realization of how central OSS is to their organization.

• Bargaining: This is when organizations start to dialog and reach out to the OSS community, often taking advantage of people’s knowledge built up through ad hoc participation and starting to focus that participation into a coherent strategy.

• Depression: At this stage, it starts to get real as other parts of the organization start to realize the OSPO’s value. Which should be great, right? Unfortunately, this is also the stage where the realization hits that OSS dependencies create a risk for the whole organization — especially when you take into account security vulnerabilities.

• Acceptance: Fully accepting that we live in an open source ecosystem means learning how to play a leadership role in that ecosystem and accepting the OSPO’s role as not only an open ecosystems center of excellence but as a security center of excellence as well.

Ok, the above is a bit of a stretch. The point is open source is here to stay. It plays a very important role in building and maintaining the vast majority of software — especially the software that we all use throughout our lives. Open source means ceding some control to the community in return for higher quality and lower operational cost. Organizations that learn to accept this fact and start playing a leadership role in that community will become market leaders. And a key part of this is security.

So how can OSPOs effectively embrace their role not only as openness champions but also as security champions? Firstly, by bringing security expertise into the OSPO team. Have a security expert on staff who is familiar with the issues around the software supply chain. Participating in the Open Source Security Foundation “End User” working group can be a way to share information in a safe forum with other similar organizations.

A great place to start is some material that has just been released from the Open Source Security Foundation (OpenSSF).

• Concise Guide for Developing More Secure Software

• Concise Guide for Evaluating Open Source Software

• NPM Best Practices Guide

All of these OpenSSF resources help people start to think about hard issues around open source security. If you’re building an OSPO or an OSPO-like function within any size organization, you’re going to be immediately familiar with some of these issues discussed in these guides. Your organization is most likely making use of npm. Your code is in source code management systems such as GitHub. You’re using open source software from a number of sources with different licenses and pedigrees. All of these issues are discussed in these guides with links off to more detailed info.

From there, OSPOs need to be hiring security people or bringing in security experts to get ahead of these issues. Start thinking about software bill of materials (SBOM) when it comes to the development, build, and deployment process. Liran Tal has a great SBOM blog post to get you started.

As a side note, it’s interesting and positive to see US legislation intended to secure open source software used in development and operation of government services that calls for the creation of OSPOs in government agencies.

Cheers to a secure (and open) 2023