Regardless of one's feelings on “the world order”, that order is rapidly changing. This may exacerbate existing risks in your software supply chain or create new and surprising ones. In chaotic situations a common saying is worry only about the things which you yourself can control. In a software supply chain with complex and intertwined dependencies, what is the changing shape of “control”?

Some say the answer is found in OSS and to a degree it may be, if the desire is sovereignty or self-reliance relative to dominant market players and proprietary solutions. But OSS is inherently global. Is this a contradiction?

It is not possible to know conclusively today where in the world are the contributors behind all the projects upon which you depend, much less their potential allegiances. Simply put: GitHub does not require upload and validation of the passport(s) of account holders, much less proof of account holder political or other affiliations.

It would be ridiculous to conceive a risk management regime that depends upon such validation.

And yet there are voices calling for exactly that, as if it would be some type of viably magic building block for success. The metaphorical silver bullet.

Barring a sudden and radical realignment of societies, the likes of which have not been seen in history, there is no silver bullet. Asymmetric advantage to the threat actors.

People > process > code

What do you do when you’re left questioning and suspicious of the very people whose code runs in the most critical and deeply embedded foundations of your business?

Going back to the value hierarchy previously discussed, if the threat is people then the answer may be an additional higher layer in that hierarchy – or the hierarchy needs rethinking.

We naturally understand all-powerful actors are the definition of unbounded threat and that needs to be constrained. This might lead to a proposed hierarchy such as:

Risk management guardrails > independent actors > project processes > project code

But risk management guardrails are process. And process is most durable when it is implemented in code. Which is perhaps to say:

Code > process > people

And there we begin to see this is actually a continuum.

People ↔ process ↔ code

Or better, the situation is something like a graph. And it is complex. See figure 4 in Baltes And Diehl's "Towards a Theory of Software Development Expertise":

What does all this mean with OSS and supply chains? Fortunately the answer is already known. 

Actively managing a software supply chain’s security means diving deeper into component quality. With OSS you have an increased opportunity, and increasingly obligation, to dive into project processes and project code, in order to gain a sense of whether people and processes and code are sufficiently trustworthy and protected against through code and process and people.

With OSS you get the opportunity to review and judge processes as well as code and automation. You can observe and judge the visible actions of people. This may feel daunting and subjective, but is often objective and even scalable as a distributed task following shared assessment frameworks collaboratively in the open.

Many projects work to ensure they themselves do not stumble due to individuals, whether incidental contributors or core maintainers. With OSS that work is visible for your inspection. Artifacts are visible with more transparency and depth than what is available in a SOC2 report, if your vendor happens to be willing to give you one.

Additionally you have the opportunity in OSS to show up and participate more actively than just reviews.

You can make a project upon which you depend objectively better. Better in people. Better in processes. And better in code. Better by more participants being there and contributing. This in turn also shaves away at one of the most challenging threat vectors: intent.