Maybe We're Doing This Software Supply Chain Security Thing Backwards.

In 1886, the Benz Motorwagen, the first commercially made motor vehicle was manufactured. This initiated the era of automotive risk. In 1938, 52 years later, the first Federal Motor Vehicle Safety Standards were established in the US, mandating that the steering wheel and other parts met certain performance standards, to mitigate that risk.

In 1989, the first commercially available internet was established, initiating the era of IT risk. It's been 34 years since then. Based on historical precedent, we have another 18 years to go before government catches up to the risk presented by software vulnerability. And it may take even longer because while car accidents killed people regularly, it still wasn't easy to convince people that regulation requiring seatbelts was a good idea, or even how to design good seatbelts (early models caused severe organ damage).

The software supply-chain security effort today is a mess. And not because we experts know exactly how to approach the problem in a cost-effective and scalable way, and are just waiting for the world to catch on. Experts like Tom Alrich lead initiatives, often volunteering time to solve this problem out of pure passion for the profession, but we're not there yet. We don't have a clear direction forward. We have some ideas and we have a few decades of trial and error ahead to figure out which of them suck and which of them don't.

But there's one direction we've already started moving in that is certainly backward: Regulations, mandates, certifications, and attestations requiring software consumers to validate the security of the software they're consuming.

Imagine if in 1938 instead of establishing the Federal Motor Vehicle Safety Standards requiring manufacturers to meet performance standards on vehicle components, the government had instead mandated that every business using vehicles validated that the manufacturers were meeting those standards. Every business would have to duplicate the same task of understanding vehicle component quality standards and then communicate with the supplier to ensure those standards are met. And to make matters worse every vehicle supplier would then have to go and answer the same questions for each of their 10,000 customers. Lots of duplicated work. Very inefficient.

Can you imagine how much of a backwards process and total headache that would be for everyone involved? If you're in cybersecurity, you probably can.

That's exactly our situation today with the validation of software supply-chain security. Various organizations and government bodies mandate that software consumers validate that the software they're consuming is secure. This is backwards.

We should focus all software supply chain security mandates, attestations, and regulations on the software suppliers, not the consumers. Mandate: All software suppliers in <country> are compliant with X, Y, Z standards. No security questionnaires. No VEX document format to address the regular tidal wave of questions about the latest CVE and whether it affects their product. No massive duplication of work. Just simple reliance on regulators to enforce a secure software supply chain apparatus, just as they do with every other product category that impacts the safety and well-being of consumers.

But Wait! What About Free Open Source Software (FOSS)?

FOSS is great stuff. I'm developing two FOSS projects now myself. But I am not a software supplier. Unless I sell the software, I am a hobbyist and a volunteer, contributing a free resource to the public. Not a secure, validated product designed to be leveraged by organizations. But that hasn't stopped organizations from using FOSS in that way.

We have to re-think that approach. With proper, traditional regulation around software products, the solution could be simple. If your organization wants to use FOSS as part of its operations, products, or services, it must either have an actual software supplier act as the intermediary to validate the quality of that software in accordance with your locally applicable regulations, or you must become a software supplier and vertically integrate those requirements into your own organization.

Write that into law, and the software supply chain security problem becomes more comparable to other quality control regulations which have worked efficiently across numerous industries since long before any of us were born. Given the historical timeline that the process of effective regulation has traversed, it's normal that we aren't there yet. But we'll get there, and hopefully sooner rather than later.

On Software Self-Suppliers

Most companies today write code to optimize and enable their operations. Meaning many companies are both software suppliers (to themselves) and consumers. This is fine if the organization is ready to take on the challenge of being a secure software supplier, but perhaps smaller orgs simply should not be developing internet-facing code themselves. This doesn't change my argument.