We need a shared vision of what basic software supply chain transparency looks like.

Hi and welcome to Cyber Reasons Mal life besides I'm Ren Lett Winston Churchill, who led Britain in World War II is credited with saying never let a good crisis go to waste.

I'm pretty sure he wasn't talking about cyber security, but you know great insights into human behavior have a tendency to be relevant across a wide range of different domains.

Software Bill of Materials, or SBAN, for short, is an idea that has been floating around for quite a few years.

It is inspired by or derived from an established practice in the field of manufacturing, one which was old

news even back in the early 2000s when I was an electronics engineer. In hardware, a bill of materials

is a list of all the different components and items,

from capacitors and resistors to silicon chips

included in a product.

Our software bill of materials is a very similar idea

just for the software side of a system.

It is a list or a nested inventory of all open source and third party software components

present in a code base.

It lists all the versions of these software components, their patch status, and even their licenses.

This way, when a new version of a software component is released or a new vulnerability is discovered in some

library, developers can easily identify which of their code bases are

affected. I think all of us can intuitively grasp how useful such a list could be.

A typical electronic board has hundreds, if not thousands of components. But when a vendor announced a recall of a leaky

capacitor or a new version of some chip, all I had to do was a simple search in my Excel files to see which of my projects used that

capacitor or cheap. Similarly, a big software project can include a large number of

third-party libraries, and to make matters worse, each

of these libraries can depend upon its own variety of other libraries, and so on and so on and so on and S-bomb can really make life easier

...