Are there too many bubbles of similar security efforts?

Earlier this year I put a shout out on LinkedIn for suggested topics to write about. Steve Springette suggested an article discussing why there are so many bubbles of similar security efforts. I get the suggestion given his work on CycloneDX through OWASP and ECMA here, and related work on SPDX through the OSSF and ISO here.

It seemed fitting to write about this now, given that last week we shared that the Software Security Project will no longer be part of the Linux Foundation, as originally planned. There will now be three efforts focused on software security, OWASP, the OSSF and the SSP, that may appear like bubbles of similar security efforts.

I suspect most people would answer the question with another question, “why can't people just work together?”. That was certainly my response for many years, but I have come to think that multiple efforts are both rational and actually yield better results for everyone in the long run. My answer to “why are there so many bubbles of similar security efforts?” is that there aren’t. What on the surface looks similar, actually isn’t. If the question was “...the same” and not “...similar”, then my answer would be different, but similar efforts usually have different goals, different ways of organizing, different types of people and different ways of doing things. These differences are indeed similar, but they are different enough for them to warrant working in parallel for the benefit of everyone.

Different horses for different courses.

The different goals of individual projects

Let's start looking at the goals of CycloneDX and SPDX. A goal is different from a mission. Goals are the more specific aims that organizations pursue to reach their visions and missions.

CycloneDX - Full BOM specification. CycloneDX describes the entire stack for which software runs. Including operating systems, containers, firmware, applications, libraries, frameworks, files, services, and optionally, hardware.

SPDX - An open standard describing SBOMs (Software Bill of Materials), communicating a release: name, version, components, licenses, copyrights, and useful security references. As a common format, SPDX reduces redundant work related to sharing important release data, thereby streamlining distribution and compliance.

On the surface they may look similar, and people think they need to make a choice, but they have two very different goals both in the area of ‘supply chain security’. CycloneDX is about BOMs that can describe everything, SPDX is about SBOMs that describe software packages. CycloneDX has a much bigger goal, which, when combined with the way the project is organized and operates (see below), explains why it has jumped the shark of SPDX and become the de facto choice for security people.

I think the goal of OWASP as a community these days, is to provide an environment where anyone can work on any type of appsec related projects, as long as the output is open source. This goal can include creating tools to secure open and closed source software.

I think the goal of the OpenSSF is for companies and organizations with a vested interest in open source, to get together and share the load of securing the open source ecosystem, so they can continue to build on it with some level of confidence.

The goal of standards bodies is to agree specifications that allow people to work better together. They set the 'rules' that define product compatibility, quality, safety, and even market access.

The goal of the SSP is to build standards, guidance, training and tools that improve the discipline of software security engineering in their companies, but output will be made free and given away for anyone that wants to use them, so the side effect will be to improve security for everyone.

As you can see, OWASP, the OpenSSF, ISO/IETF and the SSP have different goals. What may seem like bubbles of similar efforts, are not.

History Note : When I started OWASP, I was running appsec at Charles Schwab and tired of sales droids telling us what we should care about, but in the absence of anything public I could reference that had been created by genuine industry professionals, I was struggling to refute their claims. It was me against a sales droid. I wrote the OWASP Guide, published it for peer review, and the problem went away. My motivation was definitely not to improve software security, I simply wanted to defend against sales people.

Different types types of people and different ways of organizing them

One of the most significant reasons there are multiple projects, is because people want to work within a structure that they feel they can be successful in, and work with like minded people.

As I said in the intro, there will now be four efforts focused on software security, OWASP, the OSSF and the SSP. Again they may all look similar on the surface, but are actually very different. We will share details of how the SSP will operate over the next few weeks, but spoiler alert, the opinions in this article will feature heavily in those plans.

Projects like OWASP have very loose distributed governance models where the community decides what to work on. There are no priorities, no strategic plan, and no community roadmap. If you want to create a project, then as long as you follow a simple set of rules (that aren't even enforced at OWASP, let's be honest) you are good to go. It doesn't matter if it supports the overall project's mission, or is even a duplicate of existing projects, you are good to go. Governance is intentionally loose and as hands-off as possible, by design. This type of project typically attracts consultants, vendors, students and hobbyists because they can work on things that interest them or affect their businesses, however they want. I would generalize that the majority of members are technical and on the younger side.

Projects like the OSSF on the other hand, are governed by a board who are also the financial sponsors. They operate more like an industry consortium than the OWASP style of community. The governance collectively funds the community and decides on what individual projects exist and are funded. This style of governance typically attracts big tech companies, and I would generalize that the members are a mixture of management and technical, and are generally mid-career.

I have never done any meaningful work at standards bodies like the IETF and ISO but from what I understand, their governance models typically place a heavy emphasis on formality and consensus. They have a reputation for being slow and bureaucratic, and given most standards being developed are with participation from a lot of people who come from large companies, this is hardly surprising. I have never heard of anyone being enthusiastic about working inside of standards bodies, or any true innovation coming out of them as a result, but that may well be my social circle. I would generalize that the majority of members are late in their career and on the older side.

The SSP is being set up with a central governance model with clear priorities and a strategic roadmap. The governors are operational CSOs and their AppSec leaders, that is CSOs and appsec leaders at finserv, health care, gov and manufacturing and not CSOs from security vendors or consultancies. For this group of participants, their motivation is that security is not a competitive advantage for their businesses yet members are facing the same challenges, why a central governance model makes sense. I suspect the majority of members will come from mid to large size companies, will be equal part security software engineers and will be mid to later in their career.

Once again as you can see, OWASP, the OpenSSF, ISO/IETF and the SSP have different ways of organizing and different people participating. What may seem like bubbles of similar efforts, again are not.

Different ways of doing things

Community cultures are a direct reflection of the people that work in them, and the style in which they operate. Most people who work in communities of any kind, want to work with like minded people in a style that they feel comfortable with.

Bottoms up, loosely governed communities like OWASP are a great deal of fun because people get to choose to work on exactly the things they want, and in exactly the manner they want. Their way of doing things is to let people figure it out on their own. Despite my frustrations with OWASP lack of leadership (not to be confused with lack of governance although that is a part), I have always found it to be a friendly and fun place of smart and enthusiastic people because of this. Getting stuff done in your own world is easy but getting stuff done at a global level is a nightmare as I found out recently. Bottoms up projects produce a few shooting stars like CycloneDX and a whole load of, well not shooting stars.

Conversely communities with a central set of priorities and a strategic roadmap may feel more like work than a fun camp or a hobby. Participants only get to work on projects already chosen for them. They tend to be solving specific problems and so are far less innovative, but have a higher probability of having a large impact on the industry as a whole. There is always more formality and structure with centrally governed projects. The type of projects produce consistently high quality outputs that have a positive impact but rarely shooting stars.

Standard body work sounds as dull as dishwater to me.

Once again as you can see, OWASP, the OpenSSF, ISO/IETF and the SSP have different ways of doing things. What may seem like bubbles of similar efforts, again are not.

So if I want to invest my time to work on something, I would first try and find an effort that

• has a shared goal I believe in

• has a governance model I think is appropriate to achieve the goal

• I understand and am comfortable with the motivations of all the members

• I feel good about the membership and specifically feel they are like-minded

If there is nothing that is similar, then I would create one that is different, even if it does look similar on the surface. You can call that a bubble and I think that is just fine. When the tide rises, all boats float.

This is published on LinkedIn here for discussions and comments.