Might "secure by design" exacerbate market failure?

I don't usually get to spend any time in the conference at CyberUK, but this year I managed to grab a few sessions, and there was enough content to pique the interest of my engineer's brain. In almost every session there was some mention of Secure by Design. I picked up on four specific recommendations which I will give some brief initial thoughts on here:

• Use a memory safe programming language - there was lots of reference to this, and mention of Rust in particular. Rust is attractive where performance is important because it can get closer to the performance of C/C++ than, say, Java. Also, because software development is a fashion industry, we developers are really keen to learn Rust. The disadvantages at the moment include compiler issues, IDE support, existence of stable frameworks/libraries. All of this means, in the short-term at least, developing in Rust is going to be significantly less productive that in other memory safe languages like Python or Java.
• Secure hardware architectures - there was some discussions relating to the use of memory safe hardware architectures (specifically CHERI) and Morello boards. These bring additional advantages as they allow for the containment of vulnerabilities present in software written in languages which are not memory-safe. Whilst this is a white hot area of applied research, I imagine the availability of these architectures to most developers is still some way off.
• Formal methods - there was a lot of interest in the formal specification of software when I was studying Computer Science in the 1990s (VDM, Z Notation, B-Method anyone?) and their application to critical systems in particular. Since then, software development has changed radically and developers rely on libraries and frameworks to a much more significant extent. I am keen to understand what has changed in the world of Formal Methods which would allow them to be applied, whilst maintaining existing levels of productivity for the developer.
• Software Bill of Materials (SBOMs) - we've been leading on experimentation on the adoption of SBOMs at Surevine for some time. We built a Backstage.io plugin for a full CycloneDX SBOM, as part of a trial, and have been involved in discussions with both the US and UK Governments about the adoption of SBOMs. We have done this experimentally because, on the face of it, it seems useful to know what you software is made of, but it isn't yet clear what people are doing with the information in an SBOM.

There's lots here that appeal to those of who have a research interest in Computer Science. There's lots to look forward to as Engineers, but I am not sure how much most developers can apply today.

There is some talk of a "market failure" for software, but when cash-strapped public sector organisations, including our own Government, are obliged to chose the Most Economically Advantageous Tender in their procurement processes, solution providers have to continue to use the most productive means to develop software (so not much of the above, yet) or simply go out of business.

The threat of sanction (e.g. liabilities from software warranties) will have the perverse effect of meaning that only prime contractors with deep enough pockets to pay for better lawyers than Government will be able to shoulder the risk of being in the software business, increasing their monopolies, limiting choice in the market and pushing up the cost to public purse.

Now that's what I would call a market failure.