“Unsafe At Any Speed”. Comparing automobiles to code risk

Show me the incentive, and I’ll show you the outcome

The comparison between automobile risk in the 1960s and software risk in the modern era is evident. Rapid technology innovation has resulted in unsafe products being used daily. The software world, much like the automotive industry in the 60s, prioritises speed of release, features and functionality, and pushing the boundaries and limits of safe usage, all in the name of selling more products and innovating new offerings faster than your competitors. Software developers face continued pressure to release products as quickly as possible, often at the expense of the security of the code. Security is perceived as slowing down the development cycle and is often a bolt-on after the fact.

To quote the great Charlie Munger, “Show me the incentive, and I’ll show you the outcome.” Software developers don’t write secure code because they have no incentive to do so. To make matters worse, the companies they work for have very little incentive to focus on the security of their products either. IT and CISO buyers have been purchasing insecure code for as long as code has existed.

he automobile industry had a similar problem – cars purchased to that point were not bought because they were safe. People weren’t going to the automobile dealerships (did they have dealerships in the 60s?) and asking questions about the vehicle’s safety rating or if it had a collapsable steering column and padded dashboard. They purchased vehicles based on the look, the style, the top speed and acceleration, and most importantly, the joy they received while operating the new mode of transportation. Safety was not a required feature and was thus an afterthought. This is almost identical to how we have built and purchased software up through today. We prioritise and purchase based on the value we get from the software, with little to no interest in how secure it is.

There is no incentive to prioritise security when that’s not what buyers demand. The automobile industry required consumer recognition of the problem, resulting in an outcry for better safety standards before automobile manufacturers would “waste their time” on product safety features.

We won’t see an ‘Unsafe At Software Speed’ moment in 2025

The software industry hasn’t learned from the automobile industry’s past for a few key reasons. First of all, when you get into a car accident, there is a nontrivial chance of the loss of life. People die when there are no safety features present in their cars, and even a small number of deaths is unacceptable to the public. The consequences of a motor vehicle accident were immediate and visceral and left a lasting impression in the minds of those who were in one or saw one. Software is different. When the software on your TV, for example, breaks, you just reboot it.

Until recently, in the worst case, the vast majority of software flaws resulted in the compromise of some anonymous corporate entity with little to no bearing on the populace. Sure, there might be a very small chance that their accounts were compromised, money directly stolen from them, or fraud perpetrated against them, but most of the consumer world believes that “that won’t happen to me,” and by the law of large numbers, they are probably right. And if it does, they are insured, covered for loss, and, most of the time, only suffer from having to jump through lots of hoops to regain what they’ve lost.

Because of this laissez-faire attitude toward the risks, it is much easier for the software industry to ignore the problem, writing it off as a cost of doing business. In other words, there is no demand for change.

In addition to the difference in risk between automobiles and software vulnerabilities, the complexity of the software landscape dwarfs that of the automobile of the 1960s. If we could quickly implement four to six software processes and fix the entire global software risk register, I promise we would. The problem is way more complex and challenging to fix than the less than 10 large auto manufacturers of the 1960s had to figure out. If only 10 software development firms existed today, it would be easier to mandate change.

However, software is literally in everything that we touch. From IoT devices to home appliances to children’s toys – software has eaten the world, making securing that software a much more difficult task to complete. Automobile builders had to make a few changes to their products and were ready to sell. They didn’t have to change the entire manufacturing world for every product available to the public to move towards safety. Here is where the comparison falls short.

SbD and the push to secure our software

This incredible level of complexity begs the question of who is responsible for fixing the problem. In May 2024, there was a major push for software vendors to sign the “Secure by Design (SbD) pledge.” Currently, over 250 companies have committed to following secure by design principles and ensuring that their software is created with high-security standards at every step of the development process.

I love the Secure By Design pledge, but 250 companies is a drop in the bucket; according to CyberDB there are over 3,500 cyber security companies alone. These are just the companies that are working to secure our daily lives. 250 signatures is a mere blip compared to the number of companies in the United States. Some research claims over 33 million businesses in 2024 in the US alone, the bulk of which are small businesses. The difficult problem is getting to the tipping point required for businesses across the US, and the world, to realise that the risk is too high and demand change from their software vendors.

Research from the University of Pennsylvania’s Annenberg School for Communication and the School of Engineering and Applied Science shows that approximately 25% of a population is required to hit the tipping point for large-scale social change. We aren’t even close.

What I think we should be thinking about isn’t how we fix code security problems better or faster, but instead, how we get to the tipping point where the incentive structure changes and the software of the world begins to fix itself. If we think of it this way, we quickly see that change will only come when a groundswell of buyer demand and government-mandated regulations are implemented.

Fixing secure code as a movement in 2025

Given the negative outlook and tempered expectations that I’ve presented, you probably regret reading this article. I’d love for you to leave with the opposite idea in your brain and maybe approach 2025 as the year in which the software industry can move closer to the tipping point for building software more securely.

Similar to the issues discussed in Unsafe at Any Speed, companies that write software of any kind will continue to push back on ownership of the problem and attempt to deflect or ignore responsibility for any health, safety, and security issues that appear. As software is used increasingly in life-and-death situations such as healthcare, automotive, emergency communications, etc. the business and buyer demand for less risk will increase.

If we are loud enough, at some point, software liability will switch to those who are building the product, and when it does, the incentive structures will change, and companies will pay much more attention to the risks to their own business. Sadly, I don’t think we’ll ever get to the point where businesses care enough about code security to prioritise it just because it’s the right thing to do for their customers. Instead, to achieve our goals, we have to make it imperative to the health and success of their business to write more secure code, and the only way to do this is to be VERY LOUD and DEMAND CHANGE.

So, what can you do as a CISO and IT software buyer in 2025 to help move the needle and grow toward the secure code tipping point? First and foremost, we need each of you to be educated on the risks of software flaws and help articulate these issues to the developers of software that you purchase or license. Users and developers must be more aware of the importance of security and the potential consequences of software vulnerabilities to both the company that sells the software and the people that use it.

Second, and likely more critical, you must push your government representatives and agencies to become more educated on the topic and build stronger regulations and standards for secure software creation. The automobile would have never become more secure if government agencies hadn’t stepped in and put regulations and standards in place that demanded that motor vehicles have at least a minimum level of safety. We have to have regulations in the software world that place the tipping point within reach, and it’s up to the buyers and users of software to push the government on this front. Liability must shift back to the builder, which only happens when the government gets involved. It’ll take an army, but if we scream and yell loud enough over time, purchase only software that is written securely, and make a significant enough level of noise, we can continue to slowly march toward improvement.

The slow march to ‘Secure At All Speeds’

Just as Unsafe At Any Speed was a wake-up call for the automotive industry, a growing awareness of software security issues and the impact of vulnerabilities to human safety and health is building pressure for a similar reckoning in the software world. We must keep moving toward a Secure At All Speeds software development world.

I don’t think we’ll see the tipping point hit in 2025, but each of us must approach this change with a uniform rallying cry to build the volume required to be heard at the highest levels. Thank you, Jen Easterly and the CISA team, for the ground work you’ve done towards this movement, and I hope 2025 is the year where we will work together to take daily steps toward success.