• Muinin

Wait, what? There is a supply chain for software?

So let’s take a look at software development. I learn Python, then I look at the function and a rational spec of the application, and the user case. I grab a can of RedBull, fire up my computer, put on headphones and start coding right?

Nope, not the case. Not now.

The software supply chain, and its security and integrity, is a big, complex, and important topic to cover - and yet it’s not one that gets enough attention. I am going to share thoughts in three (or perhaps more!) different blog notes. This, the first, aims to align our understanding and thoughts with those from the software engineering community. We don’t think we’re completely off the mark, but we do want to bring the thoughts of others, let us know if you have questions or any feedback.

Writing software has become building software.  Like building homes and like building computers, software creation has followed the same path as cooking a meal as recently as the 1980’s to how we consume food today!

Back when I was a child, I remember my mother going to the supermarket, carrying a handwritten list, buying fresh vegetables and then making a meal from scratch. That’s how software was developed - code each piece of functionality from scratch.

Today? You go to a website and then order food,(the code analogy: SaaS software) and if I want a ‘freshly’ cooked meal, I go to a meal prep startup and then heat up the food (code analog: SaaS). If I enjoy cooking or have a dietary requirement then I can have a chef source the ingredients, provide me with step by step guide and then voila - a freshly cooked meal (code - Git, AWS, look at 10 libraries and compile a new package).  

The challenge with the new models include that in many cases you will never know the source of the vegetables, nor whether they are truly organic, nor that it hasn’t been compromised before it reaches your plate. In the case of food, we generally assume safety, since it’s a regulated industry. but how easy would it be for someone that really wanted to cause damage?

Sound comparable to the risks of a software supply chain? More code sharing and reuse has finally become possible, so we can now build great code and use specialty, pre-written code from elsewhere (who knows how to write efficient 5G radio modems AND SQL lookups AND graphical user interfaces AND then compile for a different OS AND …). But there are real issues related to that reuse, we need to ensure that the speed and agility of creating software remains intact, but it becomes feasible to do more carefully, and should be done in moderation.

In the new age of software, we have a software supply chain, like a traditional supply chain, like a food-for-cooking supply chain: some original source provides their package to a forum that delivers a specific piece of functionality.  This package is then sometimes edited and added to other packages to deliver a combination of capabilities. In the software supply chain, coordination involves making sure the right code is being developed for the product feature needed.

As Russ Cox writes: “Software dependencies carry with them serious risks that are too often overlooked. The shift to easy, fine-grained software reuse has happened so quickly that we do not yet understand the best practices for choosing and using dependencies effectively, or even for deciding when they are appropriate and when not…

… By using that code, you are exposing your own program to all the failures and flaws in the dependency. Your program’s execution now literally depends on code downloaded from (a) stranger on the internet. Presented this way, it sounds incredibly unsafe. Why would anyone do this? We do this because it’s easy, because it seems to work, because everyone else is doing it too, and, most importantly, because it seems like a natural continuation of age-old established practice.”  (See Russ’s commentary at

Against a background of current needs for rich applications and digital transformations, it is apparent that retaining the ease of use of pre-baked code ingredients while building in systems to assure their integrity is going to be a monumental endeavor.

We’re working to re-think the software supply chain, building one for integrity. We’d love your thoughts, feedback, commentary and support. Write to us!

Mehul Patel, Muinin team

42 views0 comments

Recent Posts

See All

Many Eyes

Given enough eyeballs, all bugs are shallow. - Eric S. Raymond, the Cathedral and the Bazaar Raymond’s thesis, pronounced in 1999, is that open source code, reviewable and reviewed by many reviewers,

signal: +1 415 494 7530 

© 2019 Muinín P.B.C.